From owner-cvs-src@FreeBSD.ORG  Mon May 17 15:17:30 2004
Return-Path: <owner-cvs-src@FreeBSD.ORG>
Delivered-To: cvs-src@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP
	id B340F16A4CE; Mon, 17 May 2004 15:17:30 -0700 (PDT)
Received: from daintree.corp.yahoo.com (daintree.corp.yahoo.com
	[216.145.52.172])	by mx1.FreeBSD.org (Postfix) with ESMTP
	id DD87443D4C; Mon, 17 May 2004 15:17:29 -0700 (PDT)
	(envelope-from peter@yahoo-inc.com)
Received: by daintree.corp.yahoo.com (Postfix, from userid 2154)
	id BDF848854; Mon, 17 May 2004 15:17:29 -0700 (PDT)
From: Peter Wemm <peter@wemm.org>
To: Doug Rabson <dfr@nlsystems.com>
Date: Mon, 17 May 2004 15:17:29 -0700
User-Agent: KMail/1.6.1
References: <Pine.BSF.4.21.0405171431040.27448-100000@InterJet.elischer.org>
	<200405172259.00791.dfr@nlsystems.com>
In-Reply-To: <200405172259.00791.dfr@nlsystems.com>
MIME-Version: 1.0
Content-Disposition: inline
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <200405171517.29528.peter@wemm.org>
cc: cvs-src@FreeBSD.org
cc: src-committers@FreeBSD.org
cc: Julian Elischer <julian@elischer.org>
cc: cvs-all@FreeBSD.org
Subject: Re: cvs commit: src/sys/kern kern_linker.c
X-BeenThere: cvs-src@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: CVS commit messages for the src tree <cvs-src.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/cvs-src>,
	<mailto:cvs-src-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/cvs-src>
List-Post: <mailto:cvs-src@freebsd.org>
List-Help: <mailto:cvs-src-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/cvs-src>,
	<mailto:cvs-src-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 17 May 2004 22:17:31 -0000

On Monday 17 May 2004 02:59 pm, Doug Rabson wrote:
> I've been thinking about that on and off for a while. It would be
> fairly easy to represent most of struct pcpu using TLS...

I thought about it a bit too.  One potential landmine is making sure 
that gcc can be adequately taught to be preemption safe and not cache 
pointers to the tls area across things like critical_*().  I guess that 
depends on which model is used though.  User-level threads dont have to 
worry about this, because if they're preempted, they are still the same 
thread when they come back.  pcpu isn't like this.

And to think that I was considering benchmarking a change to do an 
alpha-style stolen-register for the pcpu pointer on amd64. :-)

> On Monday 17 May 2004 22:31, Julian Elischer wrote:
> > which brings up the question of TLS in the kernel :-)
> >
> > On Mon, 17 May 2004, Peter Wemm wrote:
> > > peter       2004/05/17 14:24:40 PDT
> > >
> > >   FreeBSD src repository
> > >
> > >   Modified files:
> > >     sys/kern             kern_linker.c
> > >   Log:
> > >   Since we go to the trouble of compiling the kobj ops table for
> > > each class, and cannot handle it going away, add an explicit
> > > reference to the kobj class inside each linker class.  Without
> > > this, a class with no modules loaded will sit with an idle
> > > refcount of 0.  Loading and unloading a module with it causes a
> > > 0->1->0 transition which frees the ops table and causes
> > > subsequent loads using that class to explode.  Normally, the
> > > "kernel" module will remain forever loaded and prevent this
> > > happening, but if you have more than one linker class active,
> > > only one owns the "kernel".
> > >
> > >   This finishes making modules work for kldload(8) on amd64.
> > >
> > >   Revision  Changes    Path
> > >   1.111     +1 -0      src/sys/kern/kern_linker.c

-- 
Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com
"All of this is for nothing if we don't go to the stars" - JMS/B5