periods and deadlines in SCHED_DEADLINE
in [Kernel]
|
Prev: [PATCH 09/11] Removing dead SERIAL_BFIN_{HARD_, }CTSRTS
Next: Badness at fs/sysfs/symlink.c:82 during qeth initalization
From: Harald Gustafsson on 10 Jul 2010 13:20 2010/7/9 Peter Zijlstra <peterz(a)infradead.org>: > One thing we could do, although this would make the proposed scheduler a > wee bit more complex, is split between hard and soft realtime. Only > accept P==rel_D for hard, and schedule the soft tasks in the hard slack > or something like that. > > That way we can later extend the hard admission tests to accept more. Sorry for jumping in a bit late. I'm not that happy with this suggestion if I understand you correctly. The main reason for having deadlines shorter than the periods is for tasks that need a short response time and likely are most important for the system to be scheduled as fast as possible. Hence if they get scheduled after the tasks with deadline=period then that defeat the purpose with having a short deadline. Quite often these tasks are short and hence only need a low bandwidth, i.e. long period between activations relative to deadline and runtime. But also other use cases exist with longer running tasks (e.g. around 5-10 ms) per period (e.g. around 20 ms). You might have several of such tasks running, but as a system designer you know that their activation phase will allow them to be scheduled interleaved. This can be for example you know that the interrupt pattern waking the tasks are interleaved. The admission test would be even more complex if we also need to take into account the phases of task periods. Hence I think some of these things need to be left for the system designer without being hindered by an admission into the highest hard deadline scheduling policy. As you might have understood I'm mostly talking about embedded system, which have some tasks that are central parts of the running system but which also might in parallel run more generic software. Did I get your proposal correct? Do you agree that tasks that need to set a deadline < period usually do that since they need to be scheduled in quickly? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Harald Gustafsson on 10 Jul 2010 13:40 > Right, so I would actually expect RT job release to be triggered by > external events (say interrupts) more than on their own. And when its an > external event I don't really see the use of this new syscall. I agree that the common usage would be to wake up by an external event, rather than sleeping for a specified time period that is longer than the set period. I would assume that the period would be changed to match some generic operational unit of the task like a frame rate or packet rate, etc. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Peter Zijlstra on 10 Jul 2010 14:40 On Sat, 2010-07-10 at 19:19 +0200, Harald Gustafsson wrote: > 2010/7/9 Peter Zijlstra <peterz(a)infradead.org>: > > One thing we could do, although this would make the proposed scheduler a > > wee bit more complex, is split between hard and soft realtime. Only > > accept P==rel_D for hard, and schedule the soft tasks in the hard slack > > or something like that. > > > > That way we can later extend the hard admission tests to accept more. > > Sorry for jumping in a bit late. I'm not that happy with this > suggestion if I understand you correctly. The main reason for having > deadlines shorter than the periods is for tasks that need a short > response time and likely are most important for the system to be > scheduled as fast as possible. Hence if they get scheduled after the > tasks with deadline=period then that defeat the purpose with having a > short deadline. Quite often these tasks are short and hence only need > a low bandwidth, i.e. long period between activations relative to > deadline and runtime. > Did I get your proposal correct? Do you agree that tasks that need to > set a deadline < period usually do that since they need to be > scheduled in quickly? Sure, but 'quickly' doesn't convey whether its soft or hard RT you're interested in. The soft scheme would still have a bound on the tardiness and is quite sufficient for a large number of workloads (but of course there are plenty hard workloads too). > But also other use cases exist with longer running tasks (e.g. around > 5-10 ms) per period (e.g. around 20 ms). You might have several of > such tasks running, but as a system designer you know that their > activation phase will allow them to be scheduled interleaved. This can > be for example you know that the interrupt pattern waking the tasks > are interleaved. The admission test would be even more complex if we > also need to take into account the phases of task periods. Hence I > think some of these things need to be left for the system designer > without being hindered by an admission into the highest hard deadline > scheduling policy. As you might have understood I'm mostly talking > about embedded system, which have some tasks that are central parts of > the running system but which also might in parallel run more generic > software. That is a very delicate point, the whole reason SCHED_FIFO and friends suck so much is that they don't provide any kind of isolation, and thus, as an Operating-System abstraction they're an utter failure. If you take out admission control you end up with a similar situation. In general the sporadic task model schedulers don't need to be privileged because it does provide isolation. But the moment you allow by-passing the admission control everything goes out the window. So even a simple privileged flag telling the admission control to stuff it would render the whole system unusable, you'd have to start failing everything not having that flag, simply because the admission control is rendered useless. So I would like to take the stand that the mainline scheduler will not allow such a knob and people will have to help out with improving the admission controller. Embedded people can of course easily hack in whatever they well fancy, and adding the 'yes_I_really_want_this_anyway' flag or even taking out admission control all together is something the GPL allows them to do. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Harald Gustafsson on 10 Jul 2010 16:10 2010/7/10 Peter Zijlstra <peterz(a)infradead.org>: > Sure, but 'quickly' doesn't convey whether its soft or hard RT you're > interested in. The soft scheme would still have a bound on the tardiness > and is quite sufficient for a large number of workloads (but of course > there are plenty hard workloads too). It's soft RT (since exist ways of recover) but with high requirement on that failures being rare, e.g. once every 3000 periods due to QoS. >> But also other use cases exist with longer running tasks (e.g. around >> 5-10 ms) per period (e.g. around 20 ms). You might have several of >> such tasks running, but as a system designer you know that their >> activation phase will allow them to be scheduled interleaved. This can >> be for example you know that the interrupt pattern waking the tasks >> are interleaved. The admission test would be even more complex if we >> also need to take into account the phases of task periods. Hence I >> think some of these things need to be left for the system designer >> without being hindered by an admission into the highest hard deadline >> scheduling policy. As you might have understood I'm mostly talking >> about embedded system, which have some tasks that are central parts of >> the running system but which also might in parallel run more generic >> software. > > That is a very delicate point, the whole reason SCHED_FIFO and friends > suck so much is that they don't provide any kind of isolation, and thus, > as an Operating-System abstraction they're an utter failure. > > If you take out admission control you end up with a similar situation. OK, I see your point, and I also want to keep the isolation, its just that I thought that the complexity might be too large to be accepted by mainline. Let's work towards a solution with good admission control, i.e. having more complex admission control to handle this. > In general the sporadic task model schedulers don't need to be > privileged because it does provide isolation. But the moment you allow > by-passing the admission control everything goes out the window. So even > a simple privileged flag telling the admission control to stuff it would > render the whole system unusable, you'd have to start failing everything > not having that flag, simply because the admission control is rendered > useless. Yes, thats true if you have any truly hard RT tasks in the system. Could we have a way of making tasks with deadline=period also go into the soft deadline RT policy and not just always run before any deadline<period tasks? Maybe utilizing the flags field. In this way we rather demote all tasks than elevate some tasks above other tasks, and then the system designer could make sure that only using hard RT when needed (and supported by the admission control). Since the fact that it can be easily admission controlled is maybe not a sufficient fact for making the user want to have it as a hard RT task, running before tasks needing complex admission control. Also, without such notion the behavior might change with new kernel releases when the admission control is developed i.e suddenly some tasks will be scheduled as hard that was previously scheduled as soft deadline RT. > So I would like to take the stand that the mainline scheduler will not > allow such a knob and people will have to help out with improving the > admission controller. OK, now I agree, let's keep the hard RT, but allow soft deadline scheduling also. > Embedded people can of course easily hack in whatever they well fancy, > and adding the 'yes_I_really_want_this_anyway' flag or even taking out > admission control all together is something the GPL allows them to do. Not an option I would like to pursue, it should be possible to get a working solution without this. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Raistlin on 10 Jul 2010 18:00
On Sat, 2010-07-10 at 22:08 +0200, Harald Gustafsson wrote: > > That is a very delicate point, the whole reason SCHED_FIFO and friends > > suck so much is that they don't provide any kind of isolation, and thus, > > as an Operating-System abstraction they're an utter failure. > > > > If you take out admission control you end up with a similar situation. > > OK, I see your point, and I also want to keep the isolation, its just > that I thought that the complexity might be too large to be accepted > by mainline. Let's work towards a solution with good admission > control, i.e. having more complex admission control to handle this. > Indeed. I think things might be done step by step, relaxing the constraints as long as we find better solutions. > > Embedded people can of course easily hack in whatever they well fancy, > > and adding the 'yes_I_really_want_this_anyway' flag or even taking out > > admission control all together is something the GPL allows them to do. > > Not an option I would like to pursue, it should be possible to get a > working solution without this. > Yeah, I see your point and agree with it. Btw, I think that, even in the configuration described by Peter, if you --as an embedded system engineer-- have the full control of your device/product, you can avoid having any hard-rt task. Then, if you only have soft ones, you'll get the benefit of having the possibility of setting D!=P without suffering of any interference... Am I right? I think this could be a viable solution, at least until we have something better to relax assumptions on the schedulability test for hard tasks, isn't it? 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(a)ekiga.net / dario.faggioli(a)jabber.org |