Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752316Ab0GJScu (ORCPT ); Sat, 10 Jul 2010 14:32:50 -0400 Received: from casper.infradead.org ([85.118.1.10]:34244 "EHLO casper.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752016Ab0GJScs convert rfc822-to-8bit (ORCPT ); Sat, 10 Jul 2010 14:32:48 -0400 Subject: Re: periods and deadlines in SCHED_DEADLINE From: Peter Zijlstra To: Harald Gustafsson Cc: Raistlin , linux-kernel , Song Yuan , Dmitry Adamushko , Thomas Gleixner , Nicola Manica , Luca Abeni , Claudio Scordino , Harald Gustafsson , Bjoern Brandenburg , bastoni@cs.unc.edu, Giuseppe Lipari In-Reply-To: References: <1278682707.6083.227.camel@Palantir> <1278685800.1900.212.camel@laptop> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8BIT Date: Sat, 10 Jul 2010 20:31:50 +0200 Message-ID: <1278786710.1998.63.camel@laptop> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3630 Lines: 70 On Sat, 2010-07-10 at 19:19 +0200, Harald Gustafsson wrote: > 2010/7/9 Peter Zijlstra : > > 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/