cvs commit: src/sys/ddb db_ps.c src/sys/i386/i386 genassym.c
kern_thread.c sched_4bsd.c sched_ule.c subr_smp.c subr_witness.c src/sys/
jroberson at chesapeake.net
Thu Apr 10 12:23:41 PDT 2003
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.
> information in the scheduler specific data. I already have an entry for
> it in ULE.
More information about the cvs-all