3 ms·

So what's the downside? You almost never get optimizations like this for free. The post hints that this is also good for server workloads, but what suffers? Rea

by gxti 16y ago

So what's the downside? You almost never get optimizations like this for free. The post hints that this is also good for server workloads, but what suffers? Realtime would, but realtime usually involves a different scheduler anyway.

leif 16y ago
There isn't one. It's an existing option in the kernel, you can configure cgroups that way already, but most people don't do this so the feature is wasted. All this patch does is roughly approximate a decent-looking cgroup configuration by splitting processes by tty automatically.
- astrange 16y ago
  Of course there will be a regression if you change the scheduler policy. ck tried something similar to this and mplayer performance suffered with it (though I don't remember the details). It also broke gnome-startup because it assumed some specific schedule ordering, though this patch is more limited so it might not.
  - leif 16y ago
    When your application breaks because of scheduler ordering, You're Doing It Wrong.
    - astrange 16y ago
      Yeah, well, kernels need to support existing programs… By the way, your post is the single most obvious statement I've read this year. You got upvoted just because you capitalized some words?
      - leif 16y ago
        I got upvoted because I'm right. Kernels don't need to support horribly designed programs just because they exist, just like they don't need to support horribly designed programs that don't exist yet. Kernels support an interface and that's it. If you write code that abuses the interface, get ready to become a regression, and that'll be your own fault. (TBH I have no idea why I got upvoted, it wasn't that insightful, but I stick by what I said) (EDIT: I'm talking about gnome-startup. That's a stupid regression that never should've happened. The mplayer performance bug is totally understandable if you're mucking with the scheduler. What we really need is for someone (distros?) to pick up cgroups and provide a nice UI for it, some sane but nondestructive defaults, etc. Until then, this is a nice patch that keeps badly behaving programs from dragging down the entire system. At the very least, we mostly get user separation in multi-user environments.)
rcoder 16y ago
Since this only groups processes according to TTY/PTY, it should only affect jobs kicked off by an interactive login session. Background daemons, cron jobs, and the like all run detached from a controlling terminal, so their priority should be unaffected. As long as the fixed overhead of the patch is small (which the linked thread seems to indicate) this should be a sizable win for desktop Linux boxes without much downside for server loads.
- Confusion 16y ago
  I think gxti is asking for a quantification of 'without much'.
chibea 16y ago
The downside is that a bunch of processes started from one TTY doesn't get as much CPU as before. It basically shifts the scheduling granularity a level higher from processes to (interactive) sessions. Because that's what the question is: on which level do we want to have a fair scheduling? For a desktop user, processes have little meaning. Sessions, instead, are much more useful because they correspond better to his different tasks, for which he expects that the CPU power is distributed in a fair way.

by gxti 16y ago

leif 16y ago

There isn't one. It's an existing option in the kernel, you can configure cgroups that way already, but most people don't do this so the feature is wasted. All this patch does is roughly approximate a decent-looking cgroup configuration by splitting processes by tty automatically.

astrange 16y ago
Of course there will be a regression if you change the scheduler policy. ck tried something similar to this and mplayer performance suffered with it (though I don't remember the details). It also broke gnome-startup because it assumed some specific schedule ordering, though this patch is more limited so it might not.
- leif 16y ago
  When your application breaks because of scheduler ordering, You're Doing It Wrong.
  - astrange 16y ago
    Yeah, well, kernels need to support existing programs… By the way, your post is the single most obvious statement I've read this year. You got upvoted just because you capitalized some words?
    - leif 16y ago
      I got upvoted because I'm right. Kernels don't need to support horribly designed programs just because they exist, just like they don't need to support horribly designed programs that don't exist yet. Kernels support an interface and that's it. If you write code that abuses the interface, get ready to become a regression, and that'll be your own fault. (TBH I have no idea why I got upvoted, it wasn't that insightful, but I stick by what I said) (EDIT: I'm talking about gnome-startup. That's a stupid regression that never should've happened. The mplayer performance bug is totally understandable if you're mucking with the scheduler. What we really need is for someone (distros?) to pick up cgroups and provide a nice UI for it, some sane but nondestructive defaults, etc. Until then, this is a nice patch that keeps badly behaving programs from dragging down the entire system. At the very least, we mostly get user separation in multi-user environments.)

rcoder 16y ago

Since this only groups processes according to TTY/PTY, it should only affect jobs kicked off by an interactive login session. Background daemons, cron jobs, and the like all run detached from a controlling terminal, so their priority should be unaffected. As long as the fixed overhead of the patch is small (which the linked thread seems to indicate) this should be a sizable win for desktop Linux boxes without much downside for server loads.

Confusion 16y ago
I think gxti is asking for a quantification of 'without much'.

chibea 16y ago

The downside is that a bunch of processes started from one TTY doesn't get as much CPU as before. It basically shifts the scheduling granularity a level higher from processes to (interactive) sessions. Because that's what the question is: on which level do we want to have a fair scheduling? For a desktop user, processes have little meaning. Sessions, instead, are much more useful because they correspond better to his different tasks, for which he expects that the CPU power is distributed in a fair way.