[lkml]   [2009]   [Sep]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [RFC][PATCH] SCHED_EDF scheduling class
    On Tue, 2009-09-22 at 20:36 +0200, Peter Zijlstra wrote:
    > > The, let's say, proper task period is left to the userspace, i.e.,
    > > suspending until the next period/sporadic activation is not done in the
    > > kernel, it is up to the task.
    > > This is the most flexible interface we have been able to design, while
    > > trying to reduce the amount of information that has to be added to the
    > > minimum... Different ideas are more than welcome. :-)
    > No bright ideas at the moment, but it might be worth-while to describe
    > this task model somewhere near sched_param_ex :-)
    Well, when you have a good point... You have a good point! :-D

    > > Well, I think it might be possible, if rt is bandwidth constrained, as
    > > it is/it is becoming... Don't you?
    > Ah, the problem I see there is that your minimum deadline gets
    > constrained by whatever you configure your SCHED_FIFO bit to, this
    > doesn't seem ideal.
    Agree again, not the ideal behaviour... However, as said, I would like
    to experiment some more on this, and to (re)read the papers where they
    introduces the analysis for EDF-under-RM. :-)

    However, I should start thinking moving it upward, should I?

    > I would argue that kstopmachine is going to break pretty much
    > everything, so a workload that contains one (module unload, cpu-hotplug)
    > will not be analyzable.
    Ok, I think most of the people can stand this! :-P

    > I'd rather say that anything kstopmachine will violate RT guarantees.
    > As to migrate, I think we can model that as a regular non-preempt
    > section (we could actually remove the migrate thread and actually make
    > it such).
    I see... and do you think one more scheduling class would be needed, or
    something like 0 deadline would do the trick?

    > > This may be suboptimal and rise at least overhead, clock synchronization
    > > and locking issue, but I hope, again, it could be a start... A (bad?)
    > > solution to compare against, when designing better implementations, at
    > > least.
    > Agreed, its a pragmatic starting point, and only by implementing it can
    > we evaluate it.
    Hope it will be ready soon...

    > > Another thing I would like to have, is a task receiving a SIGXCPU if it
    > > misses its deadline, which might happen actually, e.g., if you load an
    > > UP system/a CPU more than 100% with EDF tasks.
    > Missing a deadline, and possibly over-running a deadline too.
    > Maybe add a flags field to the sched_param_ex thing ;-)
    Could be done as well... What do you mean by over-running a deadline?

    By missing, I mean that at a certain instant t, typically during a
    (hr)tick I notice that the scheduling deadline d is <= t, which means we
    probably are in overload condition, is that the same? Just to
    understand... :-)

    > > At the current time, I'm just splitting the bandwidth, and nothing more.
    > > Actually, I also think the solution is the right one, but I would really
    > > like to discuss the issues it raises.
    > Ooh, good point,.. yes we can put some exit hooks in there folding the
    > runtime back.
    > An alternative is starting the child out with 0 runtime, and have the
    > parent run sched_setscheduler() on it giving us a clear point to run
    > admission on.
    I thought this too, we just have to chose whether the 'more natural' or,
    let's say 'user friendly', behaviour is...

    Thanks again for the comments.


    <<This happens because I choose it to happen!>> (Raistlin Majere)
    Dario Faggioli, ReTiS Lab, Scuola Superiore Sant'Anna, Pisa (Italy) / /
    [unhandled content-type:application/pgp-signature]
     \ /
      Last update: 2009-09-23 14:23    [W:0.023 / U:68.788 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site