[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1253623106.4452.9.camel@laptop>
Date: Tue, 22 Sep 2009 14:38:26 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Claudio Scordino <claudio@...dence.eu.com>
Cc: Raistlin <raistlin@...ux.it>, michael@...dence.eu.com,
mingo@...e.hu, linux-kernel@...r.kernel.org, tglx@...utronix.de,
johan.eker@...csson.com, p.faure@...tech.ch,
Fabio Checconi <fabio@...dalf.sssup.it>,
Dhaval Giani <dhaval.giani@...il.com>,
Steven Rostedt <rostedt@...dmis.org>,
Tommaso Cucinotta <tommaso.cucinotta@...up.it>
Subject: Re: [RFC][PATCH] SCHED_EDF scheduling class
On Tue, 2009-09-22 at 13:58 +0200, Claudio Scordino wrote:
> > This implementation is part of a FP7 European project called ACTORS,
> > and financially supported by the European commission
> > (see http://www.actors-project.eu).
> >
> > The involved partners (which include Ericsson Research, Evidence Srl,
> > AKAtech) strongly believe that a general-purpose operating system like
> > Linux should provide a standard real-time scheduling policy (like the
> > one implemented in this patch) still allowing to schedule non-real-time
> > tasks in the usual way.
>
> Hi Peter, hi all,
>
> note that the request of having an EDF scheduling class integrated
> in the mainline kernel does not come from academy, but comes from industry.
Yeah, I know, there's lots of interest in having a deadline scheduler.
One of the things we'll have to look at is removing all the EDF
assumptions from it.
I think we'll be wanting to do something like s/EDF/DEADLINE/
s/edf/deadline/ etc. on the code base to begin with.
I think the task model as exposed through sched_param_ex needs a little
more thought as well.
But anyway, I'm very glad to see the code.. and am hoping to have some
time myself to prod at the PI code to work with this.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists