LWN: Comments on "This week in the scheduling discussion"

The SD scheduler is heaven on many server loads

mingo — 2007-06-04T09:00:09+00:00

The SD design never starves anything, ever. It has bound latency. CFS can't guarantee either as well as SD can.

The CFS design does not starve anything ever either and has bound latency. I´m wondering why you think that ¨CFS can´t guarantee either as well¨.

CPU vs disk schedulers

boniek — 2007-05-03T12:44:04+00:00

Agreed. CFQ needs more work so it can schedule writes. Glory to the developer that does this :)

CPU vs disk schedulers

eduperez — 2007-05-03T08:47:38+00:00

While I really apreciate any effort put to improve Linux in general (and CPU schedulers in particualar), I must say that I have never experienced X being sluggish because of other processes starving CPU cycles. However, processes doing intensive disk work tend to have a greater effect on responsiveness; bring some swapping to the table and the game is over...

NIH

renox — 2007-05-03T05:53:17+00:00

The general purpose OS with the best interactivity I know is/was BeOS.

I think that one of the reason of the good interactivity was that a bigger part of the GUI was inside the kernel..

I doubt that you'd be able to convince kernel developers to do the same thing.

HOWTO deny service

kbob — 2007-04-30T05:55:01+00:00

Consider an isochronous process like a real time audio processor.
It needs a time chunk every N milliseconds, so that's what it bids for.

A malicious process could outbid the audio process for a smaller timeslice
right when the audio app needs it. Then it could busy-loop for just
long enough that the audio app won't be able to finish on time.
Denial of Service.

On a longer time scale, the isochronous app might be a machine vision
system, a CD burner, or a monthly accounting report.

The malicious process wouldn't intentionally be malicious, of course.
It would just have an unfortunate self-scheduling policy.

X scheduling fairness

giraffedata — 2007-04-27T15:58:25+00:00

There is no part of the screen that's more important to get right than any other.

What if you have a long compile job running in an xterm and are simultaneously browsing the web? Wouldn't you prefer that CPU time go to drawing the browser windows than updating the xterm?

With the proposed approximation to credit transfer, it's possible for the X server to use the browser's credit on behalf of the less urgent compile job.

And even if you're simplistically setting a goal of having each consumer process get the same amount of CPU time, it's possible things would work out so the compile job would get more CPU time than the browser.

This week in the scheduling discussion

nix — 2007-04-27T14:11:16+00:00

I don't see how (assuming `breaking the bank' to equate to a DoS attack or something like that). If a process demands heaps of time in the future and doesn't use it, it'll sacrifice all its current time and end up with nothing (i.e. an idling system or other processes using the time instead). If it demands heaps of time and other things do as well, then it won't get that much time. No problem in either case.

This week in the scheduling discussion

pjones — 2007-04-26T15:40:39+00:00

There's also no way to ensure that X uses the credit for work done on the yielding process's behalf; it could just as easily squander it on wobbly window effects. But it's a step in the right direction.

I'm not so sure that squandry is a reasonable characterization of desktop effects such as "wobbly window[s]", nor that ensuring a strong coupling between credit yielded to X and work it performs is desirable.

If you've got the system configured to draw wobbly windows or other desktop effects, then any failure to draw your application's widgets in reasonable time or to wobble the windows correctly would represent the same failure. In either case, the screen looks bad and usability is degraded; the user suffers. There is no part of the screen that's more important to get right than any other. IT must all look good and perform with sufficient speed and responsiveness for the user to have a favorable experience.

The SD scheduler is heaven on many server loads

simlo — 2007-04-26T12:11:54+00:00

In practice there is not much difference between O(1) and O(log<number of tasks>). Especially since "1"=<number of priorities in the system>=140 and log<number of tasks><=log(2^64)=64.

The SD scheduler is heaven on many server loads

hmh — 2007-04-26T12:05:16+00:00

All I know is that SD seems to be all I ever wanted for regular (i.e. not HPC) servers.

The SD design never starves anything, ever. It has bound latency. CFS can't guarantee either as well as SD can. SD allows one to set the exact scheduling priority of everything and it is always respected, as there is no interactive renicing: it is very predictable.

And since one can also set the rr_interval (scheduling granularity) if the load is not latency sensitive, you can reduce its cost in context switches. It still has a few ways to go, but I hope to see in server -ck soon.

And SD is O(1), too... CFS isn't.

As someone said in LKML (maybe Con?), if the window managers were not so dumb and would renice things easily and intelligently, it might even be ideal for desktops. Oh well :-)

This week in the scheduling discussion

nowster — 2007-04-26T09:24:39+00:00

This time-as-money analogy can be extended further. I can imagine a system which has a sort of futures market in runtime...

Could a "rogue trader" break the bank? :-)

This week in the scheduling discussion

nix — 2007-04-26T08:59:29+00:00

This time-as-money analogy can be extended further. I can imagine a system which has a sort of futures market in runtime, where processes that will need runtime in the future can ask for it, costing some of its present runtime to do so and trading off against other processes which are asking for the same thing. (Asking for time at specific instants would cost more.)

This might be useful for things like multimedia apps that can tell that they have a bunch of especially hefty decoding work coming up in five seconds, or something like that.

(But I'm just babbling and have no code...)

NIH

nix — 2007-04-26T08:56:46+00:00

It's not just X. Most large systems involve one process doing work on behalf of another. (The elephant in the room, as ever, is database servers, which often have similar problems internally as well as between them and their client processes.)

Older Unixes often had *severe* X interactivity problems. X has long been famous for its jerky rendering (especially `jerky mouse syndrome') and CPU hogginess; the jerky mouse has gone away of late, but only by the cheat of running the mouse pointer at insanely high priority and because machines are now fast enough that moving a mouse pointer is cheap.

NIH

zdzichu — 2007-04-26T08:24:33+00:00

In all those technical discussions lack one (obvious?) observation. There are many unix-like systems running X. Many of them are open source and/or documented in detail. And none of them is known for having X interactivity problem. How those systems solve problem? Do they renice X? Why no developer checked, instead developing new syscalls (pushing work to userspace and making Linux more incompatibile with other *nixes) ?