cvs commit: src/sys/kern sched_ule.c

[John Baldwin]

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.

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