cvs commit: src/sys/kern sched_ule.c

[John Baldwin]

On Thursday 12 August 2004 09:50 am, John Baldwin wrote:
> On Tuesday 10 August 2004 09:18 am, John Baldwin wrote:
> > On Tuesday 10 August 2004 03:52 am, Jeff Roberson wrote:
> > > jeff        2004-08-10 07:52:22 UTC
> > >
> > >   FreeBSD src repository
> > >
> > >   Modified files:
> > >     sys/kern             sched_ule.c
> > >   Log:
> > >    - Use a new flag, KEF_XFERABLE, to record with certainty that this
> > > kse had contributed to the transferable load count.  This prevents any
> > > potential problems with sched_pin() being used around calls to
> > > setrunqueue(). - Change the sched_add() load balancing algorithm to try
> > > to migrate on wakeup.  This attempts to place threads that communicate
> > > with each other on the same CPU.
> > >    - Don't clear the idle counts in kseq_transfer(), let the cpus do
> > > that when they call sched_add() from kseq_assign().
> > >    - Correct a few out of date comments.
> > >    - Make sure the ke_cpu field is correct when we preempt.
> > >    - Call kseq_assign() from sched_clock() to catch any assignments
> > > that were done without IPI.  Presently all assignments are done with an
> > > IPI, but I'm trying a patch that limits that.
> > >    - Don't migrate a thread if it is still runnable in sched_add().
> > > Previously, this could only happen for KSE threads, but due to changes
> > > to sched_switch() all threads went through this path.
> > >    - Remove some code that was added with preemption but is not
> > > necessary.
> >
> > Couple of comments:
> >
> > 1) TDF_NEEDRESCHED is still needed as that is what manages user-level
> > preemptions.  Kernel preemption does not normally preempt threads at
> > user-level priorities (see the code in maybe_preempt() for a comment with
> > more detailed info).
> >
> > 2) Can a thread bound to CPU B ever be put on the runqueue via
> > setrunqueue() by a thread on CPU A?  If so, you need to keep the
> > SMP-specific migration check before the call to maybe_preempt() so that
> > you don't end up running the new thread on CPU A even though it is
> > supposed to run on CPU B.
>
> I'm pretty sure 2) can happen during say, a sleepq_broadcast() or
> sleepq_signal() operation.  Also for turnstile wakeups which can wakeup
> arbitrary threads on arbitrary CPUs.

Nevermind, have been educated off-list.

-- 
John Baldwin <jhb at FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/