Date: Wed, 11 Sep 2002 08:38:54 -0700 From: Luigi Rizzo <rizzo@icir.org> To: smp@freebsd.org Subject: wakeup handling on SMP boxes Message-ID: <20020911083854.A88921@iguana.icir.org>
next in thread | raw e-mail | index | archive | help
Hi,
I have a question about the handling of wakeup on SMP machine.
(I am looking at RELENG_4, but i believe the same thing happens
on CURRENT with threads instead of processes).
Imagine the following situation -- all CPUs are running cpu-bound
processes (say, all with the same priority), and at some point a
wakeup() is invoked which awakes one or more sleeping processes.
My understanding of the behaviour is that:
+ the processor handling the wakeup will suspend the
curproc and, eventually, invoke need_resched();
+ on this same processor, the priority of the newly awaken process
is compared with the one of the suspended process;
+ if the comparison succeeds, the suspended process is preempted
and the new one runs; otherwise, the new process will have a
chance at the next voluntary descheduling or roundrobin();
Am I correct ?
This seems to suggest that the priority ordering might be violated
for as much as kern.quantum, after which the roundrobin() and
forward_roundrobin() will do the right thing.
The only reason why this more or less works in practice is that the
sleeping process likely has raised its priority in the tsleep()
call, so it will preempt the process running on the processor
handling the wakeup(). On the other hand, there is no guarantee
that this process is the one with the lowest priority among those
currently running.
I guess to fix this one would need to determine if one of the
processes needs to be kicked out and replaced with the new one,
by invoking an Xcpuast IPI on the specific processor.
Any reason why this is not done ? Is the call too expensive so
one prefers to tolerate the temporary inconsistency ?
cheers
luigi
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-smp" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020911083854.A88921>