cvs commit: src/sys/ddb db_ps.c src/sys/i386/i386 genassym.c

Jeff Roberson jroberson at chesapeake.net
Thu Apr 10 13:02:17 PDT 2003


On Thu, 10 Apr 2003, Julian Elischer wrote:

>  src/sys/kern init_main.c kern_fork.c kern_mutex.c kern_proc.c kern_thread.c
>
>  sched_4bsd.c sched_ule.c subr_smp.c subr_witness.c src/sys/
> In-Reply-To: <20030410152200.M37530-100000 at mail.chesapeake.net>
> Message-ID: <Pine.BSF.4.21.0304101242270.90002-100000 at InterJet.elischer.org>
> MIME-Version: 1.0
> Content-Type: TEXT/PLAIN; charset=US-ASCII
>
>
>
> On Thu, 10 Apr 2003, Jeff Roberson wrote:
>
> > On Thu, 10 Apr 2003, Jeff Roberson wrote:
> >
> > >
> > > On Thu, 10 Apr 2003, John Baldwin wrote:
> > >
> > > >
> > > > On 10-Apr-2003 Julian Elischer wrote:
> > > > > julian      2003/04/10 10:35:45 PDT
> > > > >
> > > > >   FreeBSD src repository
> > > > >
> > > > >   Modified files:
> > > > >     sys/ddb              db_ps.c
> > > > >     sys/i386/i386        genassym.c
> > > > >     sys/kern             init_main.c kern_fork.c kern_mutex.c
> > > > >                          kern_proc.c kern_thread.c sched_4bsd.c
> > > > >                          sched_ule.c subr_smp.c subr_witness.c
> > > > >     sys/sys              proc.h
> > > > >   Log:
> > > > >   Move the _oncpu entry from the KSE to the thread.
> > > > >   The entry in the KSE still exists but it's purpose will change a bit
> > > > >   when we add the ability to lock a KSE to a cpu.
> > > >
> > > > Why not add a ke_pincpu to hold the bound CPU?  Since KSE's are in
> > > > theory a kind of virtual CPU abstraction the thread really seems to
> > > > be the wrong place for this information.
> > > >
> > >
> > > Er, this seems wrong to me.  Regardless, please but the bound cpu
> >
> > Sorry, moving the information to the thread seems wrong.  I'm not sure I
> > think it is such a good idea to so rigorously hide the kse structure.  It
> > may be nice to limit its scope but I think it is not so necessary and it
> > leads to hacks like this where information is stored in a structure where
> > it does not logically make sense.
>
> It is a thread property.
> It is "what CPU am I running on now.."
> It is set when you are switched in and unset when you are switched out.
> Between these two points you can not switch KSE so the two are
> effectively the same. The only difference is that code that has a thread
> pointer has to get it from the KSE through indirection, where it can get
> it from the thread directly.  Note that ALL cases of it being accessed
> did it via the thread pointer

Ok.

>
> There is NO support for locking a KSE to a CPU yet. That is a completely
> different question.


There is in ULE.

> >
> > > information in the scheduler specific data.  I already have an entry for
> > > it in ULE.
> > >
> > > Cheers,
> > > Jeff
> > >
> >
> >
>



More information about the cvs-src mailing list