About sched: automated per tty task groups

I am new to kernel development and I am trying to understand about new 开发者_JAVA百科kernel patch sched: automated per tty task groups .

Can some one explain in brief what exactly it is doing?

My impression of the patch (light on detail though most of the articles about it are) was that it can more evenly balance the CPU proportions in an automatic way.

The Linux CFS Completely Fair Scheduler has had a group-balancing behaviour for a while. What this means is that if user A starts 500 tasks and user B starts only one, the fairness should balance between the users, not the tasks.

To that end, all of the user A jobs should be in one group and all of user B's jobs in another, and the CPU will be shared equally among them - user A doesn't get more capacity just because they're anti-socially running more tasks.

However, the fairness was either based on user ID (dynamic) or control groups (a relatively painful, static setup method).

What this patch appears to do is to automatically allocate jobs to a group based on their TTY. In that way, the separation into group becomes an automatic feature (no setting up control groups), and one that happens on a finer grain than user ID (since typical desktops only have one user doing most of the jobs, at least the non-auto-admin ones).

So, when Linus sits down to compile the next kernel for us, the massively parallel build process has all its tasks put in one group and Linus can then fire up VLC to watch the latest episode of The Big Bang Theory (I have no idea whether he watches this show, nor whether he has various pieces of software on his box, for all I know, he may run Windows Media Player under Windows 7) in a totally separate group.

The CPU will then be shared relatively equally between the two groups, and Linus won't have to watch Sheldon jerkily move across the screen.

It'll slow down the kernel build of course, but it's not as if that's an important task he's performing for us. We can wait a little if it means his sanity levels are maintained :-)

From what I've read (and seen), this greatly improves the responsiveness of desktop applications. It doesn't give you more overall capacity but it does improve things a lot in certain scenarios.

Of course, if your usage profile is one task per TTY (or all tasks in a single TTY), it probably won't help that much. But, if it improves some scenarios and doesn't degrade too many others, it'll be a winner. And, even if it does degrade others, it's configurable behaviour, so it'll probably still sneak in to the kernel.

Interestingly enough, now that this patch candidate has gone "mainstream media", there are people coming out of the woodwork stating you can do the same thing with modifications to your .bashrc and some other minor tweaking. This basically wraps an "automated" tool around the control groups I mentioned previously.

Linus has already rejected this user-land solution since he wants it to be shell-agnostic and this is not something users should have to do:

Because it's something we want to do it for all users, and for all shells, and make sure it gets done automatically. Including for users that have old distributions etc, and make it easy to do in one place. And then you do it for all the other heuristics we can see easily in the kernel. And then you do it magically without users even having to notice.

Suddenly it doesn't seem that wonderful any more to play with bashrc, does it?

That's the point. We can push out the kernel change, and everything will "just work". We can make that feature we already have in the kernel actually be useful.

User-level configuration for something that should just work is annoying. We can do better.

Put another way: if we find a better way to do something, we should not say "well, if users want it, they can do this <technical thing here>". If it really is a better way to do something, we should just do it. Requiring user setup is not a feature.

Now, I'm not saying that we shouldn't allow users to use cgroups. Of course they can do things manually too. But we shouldn't require users to do silly things that we can more easily do ourselves.

If the choice is between telling everybody "you should do this", and "we should just do this for you", I'll take the second one every time. We know it should be done. Why should we then tell somebody else to do it for us?

I have to agree with that sentiment - if you were just allowed to tell the user they had to do something special for extra performance, you could just get them to use "nice make -j64" rather than "make -j64".