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/

[Jeff Roberson]

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.
>
> Cheers,
> Jeff
>