lkml.org 
[lkml]   [2010]   [Nov]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [RFC][PATCH 05/22] sched: SCHED_DEADLINE policy implementation
    From
    Date
    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@ekiga.net /
    dario.faggioli@jabber.org
    [unhandled content-type:application/pgp-signature]
    \
     
     \ /
      Last update: 2010-11-11 02:05    [W:4.387 / U:0.100 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site