Messages in this thread | | | Subject | Re: periods and deadlines in SCHED_DEADLINE | From | Bjoern Brandenburg <> | Date | Sun, 11 Jul 2010 08:15:23 +0200 |
| |
On Jul 10, 2010, at 9:50 AM, Raistlin wrote:
>> >> What are the exact semantics of this extra proposed syscall? >> > Right now, it is: > task_wait_interval(t) --> "wake me up at the first instant after t when > you can give me my full runtime" > >> What exactly are the benefits over not having it, and simply rely on the >> task to not wake up more often, but if it does have it run into the lack >> of budget and sort it that way? >> > What you're saying obviously will always work, and it is actually a > quite common usage pattern (we use it like that a lot! :-)). > > The new syscall might help when it is important for a task to > synchronize with the budget provisioning mechanism. It might be > uncommon, but there could be situations --more in hard than in soft > scenarios-- where you want to be sure that you're next job (and all the > subsequent ones, if you behave well) will get its full runtime, even if > this means waiting a little bit.
Isn't this basically sched_yield? Don't run me now, give lower-priority work a chance to complete, let me run again when my budget is replenished.
Otherwise, what are the semantics of sched_yield under EDF? Cycle through equal-deadline jobs? Given sporadic task activations, this is probably not very useful.
- Björn
-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |