Re: [RFC/RFT PATCH v3] sched: automated per tty task groups

["Hans-Peter Jansen" <hpj@urpla.net>]

On Tuesday 16 November 2010, 22:14:31 Lennart Poettering wrote:
> On Tue, 16.11.10 12:38, Linus Torvalds (torvalds@linux-foundation.org) 
wrote:
> > On Tue, Nov 16, 2010 at 12:33 PM, Lennart Poettering
> >
> > <mzxreary@0pointer.de> wrote:
> > > No you don't. Because that is not a desktop use case.
> >
> > See my other response. You don't care AT ALL, because by your
> > judgement, all desktop is is a web browser and a word processor.
>
> Well, I do care. But I care more about *real* problems. For example
> the fact that "updatedb" makes your system sluggish while it runs. Or
> "man-db". Or anything else that runs from cron in the background.
>
> Doing this tty dance won't help you much with background tasks such
> as man-db, updatedb and cron and its jobs, will it? They don't have
> ttys. Sorry for you. meh! Meh! meh! meh! meh!
>
> (And along comes systemd, which actually handles this properly, since
> it actually has a proper notion of what a service is, and what a
> session is, and what an app is. And which hence can control all this
> sanely.)
>
> Binding this to a tty is just solves a tiny bit of the real problem:
> i.e. your own use of make -j. End of story.

Lennart, would you mind pointing me the the paragraph that states, 
autogroup excludes any other improvements in this area?

In contrary, Linus clearly states, that this solves a long standing use 
case, that _he_ is suffering from a lot, and I bet, most of us in one 
or another way.. And it contains all that is needed: a fine selection 
of knobs for switching on/off that beast. Hopefully it can be taught to 
reveal some of its internal mechanics to the world, then all is fine. 

If you think, that systemd can solve this and probably other aspects of 
responsiveness, go for it, compete with it, and _prove_ it with real 
facts and numbers, not just hand waving. 

As already mentioned countless times (and some of it was even renamed 
for this very fact): the grouping by tty is just a starter. There are 
plenty of other possibilities to group the scheduling. The hard part is 
to find the right grouping concepts, that are making sense in the 
usability department _and_ are easy enough to be picked up from our 
favorite system and desktop environments. That's where the generic 
cgroup concept seems to be lacking ATM..

In one year from now on, our preferred distros will show, who won this 
competition. Probably both of you ;-)

Pete