Date: Thu, 24 Feb 2011 14:35:08 -0500 From: John Baldwin <jhb@freebsd.org> To: Remko Lodder <remko@elvandar.org> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, Remko Lodder <remko@freebsd.org>, src-committers@freebsd.org, davidxu@freebsd.org Subject: Re: svn commit: r219003 - head/usr.bin/nice Message-ID: <201102241435.09011.jhb@freebsd.org> In-Reply-To: <5965E5EC-A725-423A-9420-B84AD09993DC@elvandar.org> References: <201102241613.p1OGDXpM047076@svn.freebsd.org> <201102241347.39267.jhb@freebsd.org> <5965E5EC-A725-423A-9420-B84AD09993DC@elvandar.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thursday, February 24, 2011 2:03:33 pm Remko Lodder wrote:
>
> On Feb 24, 2011, at 7:47 PM, John Baldwin wrote:
>
> >>
> >
> > Are you sure that this statement applies to both ULE and 4BSD? The two
> > schedulers treat nice values a bit differently.
>
> No I am not sure that the statement applies, given your response I understand
> that both schedulers work differently. Can you or David tell me what the difference
> is so that I can properly document it? I thought that the tool is doin the same for all
> schedulers, but that the backend might treat it differently.
In the case of ULE, ULE decides first if you are interactive or not. If a
thread is interactive, nice is completely ignored. For non-interactive
threads, ULE computes a priority based on how CPU hoggish the thread is.
The nice value is then added to that priority. Thus, a nice value applied
to a slightly hoggish process might still end up with a lower priority value
(and thus "more" important) than a very hoggish process with a nice value of
0.
In 4BSD it is somewhat similar in that when you sleep on a socket ('sbwait')
or select, etc. in the kernel, the nice value is effectively ignored. 4BSD
relies on the priority values passed to tsleep(), etc. to mark interactive
processes whereas ULE uses its own set of heuristics. The effect though is
that nice is also ignored for interactive processes under 4BSD and is then
added to the resulting 'user priority' (which for 4BSD is always based on
how CPU hoggish a process is). I think for 4BSD it might be true that certain
nice values will never yield to certain other nice values, but I'm not sure
that '0' and '19' are the right numbers there.
--
John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201102241435.09011.jhb>