Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751345Ab0GKFle (ORCPT ); Sun, 11 Jul 2010 01:41:34 -0400 Received: from mail-bw0-f46.google.com ([209.85.214.46]:63519 "EHLO mail-bw0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750979Ab0GKFlc (ORCPT ); Sun, 11 Jul 2010 01:41:32 -0400 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=PY5ca2yYjSrKAj32mciQo1u7F+Unp0+ZbNWf6Ykmv6JX6jDedI46VKcn1+SRlF7q4S jN60E1KXXnjMgz1z6f/EP3pqgzqdTrN5Tp4NCJ+5se/uWpnLADQDm5jVODeVpP8ROOo8 mFvW+zAy1wG5HZyWm3fCgVCk9rB7ApCMOWOms= MIME-Version: 1.0 In-Reply-To: <1278798752.4918.24.camel@Palantir> References: <1278682707.6083.227.camel@Palantir> <1278685800.1900.212.camel@laptop> <1278786710.1998.63.camel@laptop> <1278798752.4918.24.camel@Palantir> Date: Sun, 11 Jul 2010 07:41:31 +0200 Message-ID: Subject: Re: periods and deadlines in SCHED_DEADLINE From: Harald Gustafsson To: Raistlin Cc: Peter Zijlstra , linux-kernel , Song Yuan , Dmitry Adamushko , Thomas Gleixner , Nicola Manica , Luca Abeni , Claudio Scordino , Harald Gustafsson , Bjoern Brandenburg , bastoni@cs.unc.edu, Giuseppe Lipari Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2089 Lines: 43 2010/7/10 Raistlin : > Indeed. I think things might be done step by step, relaxing the > constraints as long as we find better solutions. Yes, I definitely think the step by step approach is best here. So that eventually its possible to use hard deadline RT also for more complex task activation patterns. >> > 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? Yes, this is exactly what I mean. As long as the interface gives the user control to be able to demote a task to soft RT even if the admission control could allow it into the hard RT policy. Then later when we have managed to include more complex admission controls into the kernel, the system designer could when his system setup is handled move over to always use hard RT. This would also mean that people would start using the DL scheduler and having a motivation of improving the admission control, because it is preferred to have the benefit of reliable isolation between tasks. > 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? Yes, I agree. Regards, Harald -- 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/