cvs commit: src/sys/kern sched_ule.c
jhb at FreeBSD.org
Thu Aug 12 08:33:07 PDT 2004
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/
More information about the cvs-all