User: Password:
|
|
Subscribe / Log in / New account

Group scheduling and alternatives

Group scheduling and alternatives

Posted Dec 10, 2010 1:23 UTC (Fri) by dtlin (✭ supporter ✭, #36537)
In reply to: Group scheduling and alternatives by iabervon
Parent article: Group scheduling and alternatives

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?


(Log in to post comments)

Group scheduling and alternatives

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

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 (guest, #40338) [Link]

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]

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.


Copyright © 2018, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds