Re: [RFC][PATCH 05/22] sched: SCHED_DEADLINE policy implementation

[Raistlin]

On Wed, 2010-11-10 at 20:43 +0100, Peter Zijlstra wrote:
> On Fri, 2010-10-29 at 08:30 +0200, Raistlin wrote:
> > + * We are being explicitly informed that a new instance is starting,
> > + * and this means that:
> > + *  - the absolute deadline of the entity has to be placed at
> > + *    current time + relative deadline;
> > + *  - the runtime of the entity has to be set to the maximum value.
> 
> When exactly are we a new instance? From a quick look dl_new gets set
> after a sched_setscheduler() call, is that the only way?
> 
One of the only two ways. Later in the queue, that flag is set by a new
system call, i.e., sched_wait_interval, that can be used to inform the
scheduler (for example at the end of a periodic/sporadic job) that an
instance just ended. Moreover, it can be exploited by a task which want
the scheduler to wake it up when it can be given its full runtime.
It as been added as a consequence of the discussion happened in Dresden,
at last year RTLWS, aside of my presentation...

Whether or not this could be useful, I don't know, and I accept comments
as usual. My opinion is that it might be something worthwhile to have,
especially from the point of view of hard real-time-ish scenarios, but
we can remove it appears unnecessary.

> Could a task calling sched_setscheduler() on itself cheat the system?
>
I obviously might be wrong (especially at this time), but I would say no
for the following reasons.

If you are an overrunning -deadline task calling sched_setscheduler()
the deactivate_task->dequeue_task->dequeue_task_dl() below will trigger
the bandwidth enforcement, i.e., will set dl_throttled=1 and start
dl_timer:
	...
        on_rq = p->se.on_rq;                                                                                          
        running = task_current(rq, p);                                                                                
        if (on_rq)
                deactivate_task(rq, p, 0);
        if (running)
                p->sched_class->put_prev_task(rq, p);
	...

Later, this enqueue:
	...
	if (running)                                                                                                  
                p->sched_class->set_curr_task(rq);                                                                    
        if (on_rq) {
                activate_task(rq, p, 0);                                                                              
                                                                                                                      
                check_class_changed(rq, p, prev_class, oldprio, running);
        }
	...

even if it will find dl_new=1, will not enqueue the task back in its
dl_rq (since dl_throttled=1). The actual enqueueing happens at the
firing of dl_timer, where an update instead than a replenishment will be
performed, right because of the fact that dl_new=1. This means the
runtime will be fully replenished and the deadline moved toward
rq->clock+dl_se->dl_deadline.

Did this answer your question?

Thanks and Regards,
Dario

-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
----------------------------------------------------------------------
Dario Faggioli, ReTiS Lab, Scuola Superiore Sant'Anna, Pisa  (Italy)

http://blog.linux.it/raistlin / raistlin@xxxxxxxxx /
dario.faggioli@xxxxxxxxxx

Attachment: signature.asc
Description: This is a digitally signed message part