Re: [RFC][PATCH 02/22] sched: add extended scheduling interface

[Peter Zijlstra]

On Wed, 2010-11-10 at 23:17 +0100, Raistlin wrote:
> On Wed, 2010-11-10 at 18:28 +0100, Peter Zijlstra wrote:
> > On Fri, 2010-10-29 at 08:27 +0200, Raistlin wrote:
> > > +struct sched_param_ex {
> > > +       int sched_priority;
> > > +       struct timespec sched_runtime;
> > > +       struct timespec sched_deadline;
> > > +       struct timespec sched_period;
> > > +       unsigned int sched_flags;
> > > +
> > > +       struct timespec curr_runtime;
> > > +       struct timespec used_runtime;
> > > +       struct timespec curr_deadline;
> > > +}; 
> > 
> > It would be better for alignment reasons to move the sched_flags field
> > next to the sched_priority field.
> > 
> Makes sense, thanks. :-)
> 
> > I would suggest we add at least one more field so we can implement the
> > stochastic model from UNC, sched_runtime_dev or sched_runtime_var or
> > somesuch.
> > 
> Ok, no problem with that too.
> 
> 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.

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.

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.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/