lkml.org 
[lkml]   [2010]   [Jul]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: periods and deadlines in SCHED_DEADLINE
    From
    Date

    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/

    \
     
     \ /
      Last update: 2010-07-11 08:19    [W:4.393 / U:0.300 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site