Date: Thu, 12 Aug 2004 09:50:08 -0400 From: John Baldwin <jhb@FreeBSD.org> To: Jeff Roberson <jeff@FreeBSD.org> Cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/kern sched_ule.c Message-ID: <200408120950.08724.jhb@FreeBSD.org> In-Reply-To: <200408100918.45387.jhb@FreeBSD.org> References: <200408100752.i7A7qMYI000506@repoman.freebsd.org> <200408100918.45387.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200408120950.08724.jhb>