cvs commit: src/sys/kern sched_ule.c

John Baldwin jhb at FreeBSD.org
Thu Aug 12 06:51:01 PDT 2004


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.

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


More information about the cvs-src mailing list