Messages in this thread | | | Subject | Re: periods and deadlines in SCHED_DEADLINE | From | Peter Zijlstra <> | Date | Sat, 10 Jul 2010 17:11:28 +0200 |
| |
On Sat, 2010-07-10 at 09:50 +0200, Raistlin wrote:
> Hey, fine, where's the problem? :-P
We're talking about it.. the exact semantics and the reasons therefore ;-)
> > 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. > > what I was wondering was if this semantic should be modified by the > introduction of the "period", but I also agree with Luca that we must do > our best to avoid confusion!
Right, so I would actually expect RT job release to be triggered by external events (say interrupts) more than on their own. And when its an external event I don't really see the use of this new syscall.
I guess I'm asking for what reason RT tasks would be ever be self-releasing, it seems, odd..
| |