Re: periods and deadlines in SCHED_DEADLINE

[Peter Zijlstra <peterz@infradead.org>]

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..