[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 11 Nov 2010 14:54:08 +0100
From: Raistlin <raistlin@...ux.it>
To: Peter Zijlstra <peterz@...radead.org>
Cc: Ingo Molnar <mingo@...e.hu>, Thomas Gleixner <tglx@...utronix.de>,
Steven Rostedt <rostedt@...dmis.org>,
Chris Friesen <cfriesen@...tel.com>, oleg@...hat.com,
Frederic Weisbecker <fweisbec@...il.com>,
Darren Hart <darren@...art.com>,
Johan Eker <johan.eker@...csson.com>,
"p.faure" <p.faure@...tech.ch>,
linux-kernel <linux-kernel@...r.kernel.org>,
Claudio Scordino <claudio@...dence.eu.com>,
michael trimarchi <trimarchi@...is.sssup.it>,
Fabio Checconi <fabio@...dalf.sssup.it>,
Tommaso Cucinotta <cucinotta@...up.it>,
Juri Lelli <juri.lelli@...il.com>,
Nicola Manica <nicola.manica@...i.unitn.it>,
Luca Abeni <luca.abeni@...tn.it>,
Dhaval Giani <dhaval@...is.sssup.it>,
Harald Gustafsson <hgu1972@...il.com>,
paulmck <paulmck@...ux.vnet.ibm.com>
Subject: Re: [RFC][PATCH 02/22] sched: add extended scheduling interface
On Thu, 2010-11-11 at 14:32 +0100, Peter Zijlstra wrote:
> > BTW, as Dhaval was suggesting, are (after those changes) fine with this
> > new sched_param? Do we need some further mechanism to grant its
> > extendability?
> > Padding?
> > Versioning?
> > void *data field?
> > Whatever?
> >
> > :-O
> >
> > I'd like very much to have some discussion here, if you think it is
> > needed, in hope of avoiding future ABI issues as much as possible! :-P
>
> Right, so you mentioned doing s/_ex/2/ on all this stuff, which brings
> it more in line with that other syscalls have done.
>
Sure, this is necessary and easy to achieve. :-)
> The last three parameters look to be output only as I've not yet found
> code that reads it, and __getparam_dl() doesn't even appear to set
> used_runtime.
>
Yeah, just kind of statistical reporting of the task's behaviour. That's
why I was in agreement with Dhaval about using schedstats for those
(bumping the version, obviously). What do you think?
> One thing you can do is add some padding, versioning and void*
> extentions are doable for the setparam() path, but getparam() is going
> to be mighty interesting.
>
Mmm... So, tell me if I got it well: I remove the last three parameters
(e.g., moving them toward schedstats) and add (besides _var and _max)
some padding? It that correct?
what about the len <== sizeof(struct sched_param2) in
sched_{set,get}{param,scheduler}2()... Does this still make sense, or
are we removing it?
Thanks,
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@...ga.net /
dario.faggioli@...ber.org
Download attachment "signature.asc" of type "application/pgp-signature" (199 bytes)
Powered by blists - more mailing lists