[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.133 / U:1.392 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site