Re: [PATCH v4] sched: automated per session task groups

[Jesper Juhl]

On Sun, 5 Dec 2010, Colin Walters wrote:

> On Sun, Dec 5, 2010 at 3:47 PM, Linus Torvalds
> <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:
> >
> > The semantics of "nice" are not - and have never been - to put things
> > into process scheduling groups of their own.
> 
> Again, I obviously understand that - the point is to explore the space
> of changes here and consider what would (and wouldn't) break.  And
> actually, what would improve.
> 
> > This is very much documented. People rely on it.
> 
> Well, we established my Fedora 14 system doesn't.  You said "no one"
> uses "nice" interactively.  So...that leaves - who?  If you were
> saying to me something like "I know Yahoo has some code in their data
> centers which uses a range of nice values; if we made this change, all
> of a sudden they'd get more CPU contention..."  Or like, "I'm pretty
> sure Maemo uses very low nice values for some UI code".  But you so
> far haven't really done that, it's just been (mostly)
> assertions/handwaving.  Now you obviously have a lot more experience
> that gives those assertions and handwaving a lot of credibility - but
> all we need is one concrete example to shut me up =)
> 
[...]

I'll give you two re-world examples from two (closed source, but 
still) apps we develop at my current employer.

The first one is a server/network monitoring app where there are lots of 
child processes devoted to performing checks, storing data, displaying 
results etc. Most of these processes just run at the default nice level. 
One of the processes sometimes has a need for a cryptographic key pair and 
it can generate this when it needs it, but it's better if one is reaily 
available, so we have a seperate child process running that maintains a 
small pool of new key pairs - this process runs at a high nice level since 
it should not take CPU time away from the rest of the processes (it's not 
important, it's just a small optimization), the need for key pairs comes 
at large intervals, so the pool will almost never be depleted even if 
this process doesn't get very much CPU time for a long time and besides, 
if the pool ever gets depleted its no disaster since the consumer will 
then just generate a key pair when needed and burn the required CPU.

The second is a backup aplication where one child process is in charge of 
doing background disk scanning, compression and encryption. This process 
is not interactive, it must result in minimal interference with whatever 
the user is currently using the machine for as his primary task and 
time-to-completion is not really that important. So, this process runs at 
a rather high nice level to avoid stealing CPU from the users primary 
task(s).


-- 
Jesper Juhl <jj@xxxxxxxxxxxxx>            http://www.chaosbits.net/
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/