Date: Mon, 24 Jan 2000 20:00:54 +1100 (EST) From: Bruce Evans <bde@zeta.org.au> To: Warner Losh <imp@village.org> Cc: Mikhail Teterin <mi@kot.ne.mediaone.net>, Dan Nelson <dnelson@emsphone.com>, Jason Evans <jasone@canonware.com>, David Schwartz <davids@webmaster.com>, bde@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: kern/13644 Message-ID: <Pine.BSF.4.21.0001241920560.1206-100000@alphplex.bde.org> In-Reply-To: <200001240600.XAA01269@harmony.village.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 23 Jan 2000, Warner Losh wrote:
> : This is what I asked for, when I asked for "other specification". Could
> : you provide the chapter/verse number of where POSIX spec contradicts the
> : man pages? It will help me make my case on the TCL forum, since the TCL
> : developers remain under the mistaken assumption, that select() may
> : return earlier, but never later than specified.
>
> That's trivially easy to show.
In theory, but not in practice :-).
> Given process X with a priority N + 1 that is doing
N - 1 (higher priority is actually "lower")
> while (1) ;
> while process Y with a priority of N is doing the select. The kernel
> won't prempt X until the time slice is done, which can be a long
> time. If the select'd process is swapped out, then it could take a
> very very long time to swap back in.
Um, if the priorities are actually N vs. N - 1, then the process with
priority N won't run at the end of the timeslice. It will only run
when its priority becomes "lower", possibly several timeslices later.
In practice, the priorities will never be N vs. N - 1. The process
doing the select() sleeps at priority PSOCK = 24. The process doing
the while loop should always have priority >= PUSER = 50, but due to
a bug (?) in nice(2), the priority of a nice --20 process can be as
low as PUSER - 20 = 30. Anyway, that is > PSOCK, so the process doing
the select() will preempt the user process and wake up as soon as it
times out. Then, due to a longstanding scheduling bug (?), the process
doing the select() will return to userland without being rescheduled,
although its user priority may be much "higher" than that of any other
runnable process. Processes that do i/o are thus preferred to cpu
hogs much more strongly than their priorities indicate. This bug is
a feature in most cases. It reduces context switches. Interactive
process may get more benefit from it than from the classical scheduling
preference for interactive processes.
Bruce
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0001241920560.1206-100000>