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.
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.
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.
>
> 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.
Oh, and their model has something akin to: sched_runtime_max, these
Gaussian bell curves go to inf. which is kinda bad for trying to compute
bounds.
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
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 / [email protected] /
[email protected]
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;
> > +};
>
> 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.
>
Moreover, I really think that the capability of reporting back current
and used runtime (and deadline) would be very useful for implementing
more complex (and effective) scheduling behaviour in userspace... And in
fact I added them here.
Something I was not so sure, and thus about what I wanted your opinion,
was if I should put these things here --so that they are retrievable by
a sched_getparam[_ex, 2], or either add yet another syscall specific for
that? Thoughts?
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 / [email protected] /
[email protected]
Il 10/11/2010 20:26, Peter Zijlstra ha scritto:
>> 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.
> Oh, and their model has something akin to: sched_runtime_max, these
> Gaussian bell curves go to inf. which is kinda bad for trying to compute
> bounds.
If I understand well the paper you're referring to, the actual admission
test would require also to specify a maximum acceptable expected
tardiness, and/or proper quantiles of the tardiness distribution, and
also it would require to solve a linear programming optimization problem
in order to check those bounds. You don't want this stuff to go into the
kernel, do you ?
There are plenty of complex schedulability tests for complex (and also
distributed) RT applications modeled in a more or less complex way,
scheduled under a variety of scheduling policies, with models including
maximum and stochastic blocking times, task dependencies, offsets, and I
don't know whatever else. These tests may be part of a user-space
component. I would recommend to keep at the kernel level only a bare
minimal set of functionality.
Deadlines different from periods are already a first complexity that I'm
not sure we want to have in the interface. The easiest thing you can do
there is to consider simply the minimum among the relative deadline and
the period, but that would be equivalent to having only one parameter.
More importantly, realizing complex admission control tests raises the
issue of how to represent the "availability of RT CPU power" (as needed
by "higher-level" logic/middleware). As far as we keep simple
utilization-based admission tests (which might optionally be disabled),
we still have some chance of representing such quantity.
Apologies for my 2 poor cents. I hope to see here a discussion (and I'll
try to shut-up as much as possible :-) ).
T.
--
Tommaso Cucinotta, Computer Engineering PhD, Researcher
ReTiS Lab, Scuola Superiore Sant'Anna, Pisa, Italy
Tel +39 050 882 024, Fax +39 050 882 003
http://retis.sssup.it/people/tommaso
Il 10/11/2010 23:17, Raistlin ha scritto:
>> 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.
> Do we need some further mechanism to grant its
> extendability?
> Padding?
> Versioning?
> void *data field?
> Whatever?
This is a key point. Let me copy text from a slide of my LPC main-conf talk:
Warning: features & parameters may easily grow
- Addition of parameters, such as
- deadline
- desired vs guaranteed runtime (for adaptive reservations &
controlled overcommitment)
- Set of flags for controlling variations on behavior
- work conserving vs non-conserving reservations
- what happens at fork() time
- what happens on tasks death (automatic reclamation)
- notifications from kernel (e.g., runtime exhaustion)
- Controlled access to RT scheduling by unprivileged
applications (e.g., per-user “quotas”)
- Monitoring (e.g., residual runtime, available bandwidth)
- Integration/interaction with power management
(e.g., spec of per-cpu-frequency budget)
How can we guarantee extensibility (or replacement) of parameters in the
future ?
What about something like _attr_*() in POSIX-like interfaces ?
T.
--
Tommaso Cucinotta, Computer Engineering PhD, Researcher
ReTiS Lab, Scuola Superiore Sant'Anna, Pisa, Italy
Tel +39 050 882 024, Fax +39 050 882 003
http://retis.sssup.it/people/tommaso
On Thu, 2010-11-11 at 00:33 +0100, Tommaso Cucinotta wrote:
> Il 10/11/2010 20:26, Peter Zijlstra ha scritto:
> >> 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.
> > Oh, and their model has something akin to: sched_runtime_max, these
> > Gaussian bell curves go to inf. which is kinda bad for trying to compute
> > bounds.
> If I understand well the paper you're referring to, the actual admission
> test would require also to specify a maximum acceptable expected
> tardiness, and/or proper quantiles of the tardiness distribution, and
> also it would require to solve a linear programming optimization problem
> in order to check those bounds. You don't want this stuff to go into the
> kernel, do you ?
I'm not sure it does, the admission test only uses the average runtime
and uses the fact that it averages out to this (or less) to ensure
tardiness is bounded.
So the stochastic model allows for temporal overload situations but
because of the average nature next jobs must make up for the overrun of
a previous job, negating the overload.
So on average the system isn't overloaded.
The only reason we need the max runtime limit is because avg+stdev dont
actually place a bound on anything, like said the Gaussian bell curve
goes all the way out to infinity.
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.
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 / [email protected] /
[email protected]
On Thu, Nov 11, 2010 at 02:32:13PM +0100, Peter Zijlstra wrote:
> 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.
>
So, do you think its a good idea moving this information to schedstats?
It seems more in line for monitoring, which schedstat seems a more
appropriate destination.
thanks,
Dhaval
On Thu, 2010-11-11 at 14:54 +0100, Raistlin wrote:
> > 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?
So its pure output? In that case its not really a nice fit for
sched_param, however..
I'm not really a fan of schedstat, esp if you have to use it very
frequently, the overhead of open()+read()+close() + parsing text is
quite high.
Then again, if people are really going to use this (big if I guess) we
could add yet another syscall for this or whatever.
> > 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?
grmbl, so I was going to say, just pad it to a nice 2^n size, but then I
saw that struct timespec is defined as two long's, which means we're
going to have to do compat crap.
Thomas is there a sane time format in existence? I thought the whole
purpose of timeval/timespec was to avoid having to use a u64, but then
using longs as opposed to int totally defeats the purpose.
> 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?
Since we're going for a constant sized structure we might as well take
it out.
On Thu, 2010-11-11 at 15:08 +0100, Peter Zijlstra wrote:
> I'm not really a fan of schedstat, esp if you have to use it very
> frequently, the overhead of open()+read()+close() + parsing text is
> quite high.
>
> Then again, if people are really going to use this (big if I guess) we
> could add yet another syscall for this or whatever.
>
Ok, we'll see at that time.
> grmbl, so I was going to say, just pad it to a nice 2^n size, but then I
> saw that struct timespec is defined as two long's, which means we're
> going to have to do compat crap.
>
> Thomas is there a sane time format in existence? I thought the whole
> purpose of timeval/timespec was to avoid having to use a u64, but then
> using longs as opposed to int totally defeats the purpose.
>
Fine, and u64 will be. Going for that...
> > 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?
>
> Since we're going for a constant sized structure we might as well take
> it out.
>
... and for that!
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 / [email protected] /
[email protected]