Messages in this thread | | | Subject | Re: [RFC][PATCH 02/22] sched: add extended scheduling interface | From | Peter Zijlstra <> | Date | Thu, 11 Nov 2010 14:32:13 +0100 |
| |
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.
| |