Date: Wed, 11 Sep 2002 17:21:43 -0700 From: Luigi Rizzo <rizzo@icir.org> To: Bruce Evans <bde@zeta.org.au> Cc: smp@FreeBSD.ORG Subject: Re: wakeup handling on SMP boxes Message-ID: <20020911172143.H93521@iguana.icir.org> In-Reply-To: <20020912041647.U3346-100000@gamplex.bde.org>; from bde@zeta.org.au on Thu, Sep 12, 2002 at 05:18:34AM %2B1000 References: <20020911083854.A88921@iguana.icir.org> <20020912041647.U3346-100000@gamplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Sep 12, 2002 at 05:18:34AM +1000, Bruce Evans wrote: ... > > + 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(); > > If the newly awaken process has a higher priority than the current process, > then the current process's rescheduling flag is set and the current ok, i was mostly interested on the bogus handling of the "otherwise" case (in SMP). > > 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. > > Only if the process stays in the kernel that long. The quantum is not ... > Processes are supposed to sleep at a high (or suitable) priority so that now, this is another debatable thing -- why do processes sleep at high priority at all given that they are not holding any locks while sleeping ? > I think it would be too expensive to switch contexts on every significant > priority change even under !SMP. but isn't that what actually happens already most of the times ? The woken up process has a higher priority than userland processes so it always causes a reschedule when the CPU returns to a user context ? The additional cost under SMP would be the Xcpuast IPI -- how expensive it is on both the sender and the receiver i have no idea though, does it require the sender to spin until the receiver has cleared the flag ? 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?20020911172143.H93521>