SCHED_DEADLINE returns
The deadline scheduler patches now have a new developer in the form of Juri
Lelli; Juri has posted a new version of the
patches to restart the discussion. The changes from the last time
around are mostly minor: review comments addressed and an improved
migration mechanism added. The plan is to continue to fill in the gaps
required to make the deadline scheduler production-worthy and, eventually,
to get it into the mainline. To that end, there is a new git repository,
an application designed to test deadline scheduling, and a new mailing list.
One assumes Juri would be most appreciative of testing and patches.
Index entries for this article | |
---|---|
Kernel | Scheduler/Deadline scheduling |
Posted Apr 12, 2012 7:24 UTC (Thu)
by flok (subscriber, #17768)
[Link] (2 responses)
Posted Apr 12, 2012 19:24 UTC (Thu)
by dlang (guest, #313)
[Link] (1 responses)
1. how can the application know this? (the time will vary depending on how well caching works)
2. what do you do with an application that ends up using more than it claimed it would?
Posted Apr 12, 2012 19:39 UTC (Thu)
by corbet (editor, #1)
[Link]
As for what happens if you blow the WCET: the deadline scheduler just freezes you out until the next scheduling period starts.
Posted Apr 12, 2012 11:32 UTC (Thu)
by armisx (guest, #83957)
[Link] (2 responses)
Posted Apr 13, 2012 16:08 UTC (Fri)
by bronson (subscriber, #4806)
[Link] (1 responses)
Posted Apr 14, 2012 1:51 UTC (Sat)
by nevets (subscriber, #11875)
[Link]
SCHED_DEADLINE returns
SCHED_DEADLINE returns
Of course, deadline scheduling depends on exactly this: an application must declare a worst-case execution time along with its deadline. Knowing what the WCET should be is, of course, not a small problem; it's currently fodder for a number of academic careers, I think. Usual practice, I suspect, is to determine it empirically.
SCHED_DEADLINE returns
SCHED_DEADLINE returns
SCHED_DEADLINE returns
SCHED_DEADLINE returns