Group scheduling and alternatives

Posted Dec 9, 2010 16:38 UTC (Thu) by jwarnica (subscriber, #27492)
Parent article: Group scheduling and alternatives

If we are going to expect applications to properly announce their requirements, we might as well get rid of the pesky OS and code to bare metal. Or for something less extreme, just slide back to cooperative multitasking.

Its like asking users what they want. Everything, now, for free. Of course! Thanks for that.

Group scheduling and alternatives

Posted Dec 9, 2010 22:48 UTC (Thu) by iabervon (subscriber, #722) [Link] (6 responses)

Just because the application asks for something doesn't mean it gets it. Currently, the kernel acts as if applications all want all of the processor time. But some applications actually only want some of the processor time. If an application can only make use of the first 1 us of every 1 ms, and asks to run only then, the kernel may be able to give it 100% of the time it wants without any system impact; if, on the other hand, it can't tell the kernel, it has to busy-wait through a lot more processor time in order to get any change of being running then, and load the system much more heavily.

The right design is to assume that programs want everything, and let them say what they don't want. Then you don't give them anything they don't want. Then the usual fairness and best effort goals essentially work again: if you have a batch process and a realtime process of the same priority, it is equally bad to miss the realtime process's window once as to not run the batch process at all for 1 ms; that is, the scheduler should try equally hard to avoid either happening, and fail about equally often under random load. Of course, writing a scheduler that does this optimally is hard, but the theory shows that it is possible to give userspace controls such that a program can benefit by decreasing its demands on the system.

Group scheduling and alternatives

Posted Dec 10, 2010 1:23 UTC (Fri) by dtlin (subscriber, #36537) [Link] (4 responses)

If an application can only make use of the first 1 us of every 1 ms, and asks to run only then, the kernel may be able to give it 100% of the time it wants without any system impact; if, on the other hand, it can't tell the kernel, it has to busy-wait through a lot more processor time in order to get any change of being running then, and load the system much more heavily.

What's wrong with nanosleep?

Group scheduling and alternatives

Posted Dec 10, 2010 2:46 UTC (Fri) by iabervon (subscriber, #722) [Link] (3 responses)

Last time I tried it, if the kernel happened to start running a different process 98 us before your sleep was scheduled to complete, and the other process was getting a 100 us slice, it would wake you 2 us after the start of the millisecond, when your process can't do anything other than record the loss of a sample and go back to sleep for 998 us. nanosleep is fine for telling the kernel you can't do anything until a given time, but it doesn't tell the kernel that, in 999 us, there will be 1 us that you can use, followed by another 999 us during which your either done or too late to do anything.

The scales in my example are different from what I was actually doing at the time, but I was trying to sample an accelerometer attached to an i2c bus attached to a serial port at 20 Hz; I needed to send a few bytes at the right time, which would cause the accelerometer to take a sample then. (The accelerometer device didn't support automatic periodic sampling.) It turned out that the only way to get data that I could analyze was to sleep until 1 ms before the time I wanted to sample and busy-wait until the right time; that meant I was generally running by the sample time, and generally hadn't used up my time slice. On the other hand, I was burning ~2% of the CPU on a power-limited system busy-waiting.

Group scheduling and alternatives

Posted Dec 10, 2010 18:08 UTC (Fri) by njs (subscriber, #40338) [Link] (2 responses)

I'm surprised -- on modern Linux, if you make use of RT scheduling (and especially if you can use the -rt branch) then I think you should be able to get <1 ms wakeup resolution.

Group scheduling and alternatives

Posted Dec 10, 2010 18:38 UTC (Fri) by iabervon (subscriber, #722) [Link] (1 responses)

This was, admittedly, a while ago, on a vanilla kernel. But I also didn't want to need any special scheduling capabilities. I'd be okay with dropping the occasional sample under heavy load (so it's not really a real-time critical task), but just sleeping was causing me to drop lots of samples under minimal load.

Group scheduling and alternatives

Posted Dec 20, 2010 1:44 UTC (Mon) by kevinm (guest, #69913) [Link]

sched_setscheduler(SCHED_FIFO) combined with the nanosleep() should get you there.

Group scheduling and alternatives

Posted Dec 16, 2010 20:36 UTC (Thu) by oak (guest, #2786) [Link]

Doesn't work as developers are "lazy". I think default needs to be some middle ground so that some processes can say they need more and some can say then need less (priority, scheduling accuracy...). Former group because they've been found to have problems and latter because they've been found to cause problems. I.e. minimize the number of programs that need to be modified to get system behave properly.