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

[Jesper Juhl]

On Sun, 5 Dec 2010, Jesper Juhl wrote:

> 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).
> 

Ohh and a third example. On my home laptop I got sufficiently annoyed with 
'updatedb' starting up from cron while I was in the middle of something 
so that cron job now runs updatedb with 'nice 19' and also uses ionice so 
it runs at the 'best effort' class and with priority 7 (lowest).


-- 
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/