Messages in this thread | | | Subject | Re: [RFC][PATCH] SCHED_EDF scheduling class | From | Raistlin <> | Date | Wed, 23 Sep 2009 14:19:52 +0200 |
| |
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.
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] | |