Date: Thu, 12 Aug 2004 10:04:20 -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: <200408121004.20078.jhb@FreeBSD.org> In-Reply-To: <200408120950.08724.jhb@FreeBSD.org> References: <200408100752.i7A7qMYI000506@repoman.freebsd.org> <200408100918.45387.jhb@FreeBSD.org> <200408120950.08724.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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@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?200408121004.20078.jhb>