Date: Thu, 12 Sep 2002 23:41:54 +1000 (EST) From: Bruce Evans <bde@zeta.org.au> To: Luigi Rizzo <rizzo@icir.org> Cc: smp@FreeBSD.ORG Subject: Re: wakeup handling on SMP boxes Message-ID: <20020912232323.G6445-100000@gamplex.bde.org> In-Reply-To: <20020912043148.B98062@iguana.icir.org>
index | next in thread | previous in thread | raw e-mail
On Thu, 12 Sep 2002, Luigi Rizzo wrote: > On Thu, Sep 12, 2002 at 09:05:45PM +1000, Bruce Evans wrote: > ... > > > 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 ? > > > > So that they get run soon after they wake up. The priority doesn't matter > > while they are asleep, but the system needs to know what priority to use > > when it wakes them. > > ok but why they need to run soon ? again, they are not holding any > resource, so they could as well keep their priority and be > scheduled according to it (which is something that will happen > anyways when they do an usrret). First, they might need a high priority when they wake up because the event that woke them up is urgent. The easiest way to ensure that the urgent events are handled as soon as possible is to wake up at highest priorty and decide then. In practice, urgency is predicted in advance (PRIBIO Is higher (numerically lower) than PSOCK, etc.). Second, if processes just went to sleep with their current priority, that priority would normally be the user priority that they happen to be running at and it wouldn't be properly raised while they are asleep. So they must switch to some kernel priority, and that priority may as well be the process's best estimate at the priority it should have when it wakes up. I think the values of kernel priority don't actually matter much. If there are no competing processes in the kernel, then any priority will do. If there are some, then in most cases it doesn't help for them to be different, since scheduling decisions usually aren't acted on until the current process returns to user mode. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the messagehelp
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020912232323.G6445-100000>