On Fri, 2010-10-29 at 08:36 +0200, Raistlin wrote:
> Make it available for the user-space the total amount of runtime
> time it has used from since it became a -deadline task.
>
> This is something that is typically useful for monitoring from
> user-space the task CPU usage, and maybe implementing at that level
> some more sophisticated scheduling behaviour.
>
> One example is feedback scheduling, where you try to adapt the
> scheduling parameters of a task by looking at its behaviour in
> a certain interval of time, applying concepts coming from control
> engineering.
>
> Signed-off-by: Dario Faggioli <[email protected]>
> ---
> include/linux/sched.h | 7 +++----
> kernel/sched.c | 3 +++
> kernel/sched_debug.c | 1 +
> kernel/sched_dl.c | 1 +
> 4 files changed, 8 insertions(+), 4 deletions(-)
>
> diff --git a/include/linux/sched.h b/include/linux/sched.h
> index 8ae947b..b6f0635 100644
> --- a/include/linux/sched.h
> +++ b/include/linux/sched.h
> @@ -1242,14 +1242,15 @@ struct sched_rt_entity {
> #endif
> };
>
> -#ifdef CONFIG_SCHEDSTATS
> struct sched_stats_dl {
> +#ifdef CONFIG_SCHEDSTATS
> u64 last_dmiss;
> u64 last_rorun;
> u64 dmiss_max;
> u64 rorun_max;
> -};
> #endif
> + u64 tot_rtime;
> +};
>
I know we agreed to pull this from the sched_param2 structure and delay
exposing this information for a while until the base patches got merged
and came up with a solid use-case, but reading this patch makes me
wonder why tsk->se.sum_exec_runtime isn't good enough?
On Thu, 2010-11-11 at 20:37 +0100, Peter Zijlstra wrote:
> > -#ifdef CONFIG_SCHEDSTATS
> > struct sched_stats_dl {
> > +#ifdef CONFIG_SCHEDSTATS
> > u64 last_dmiss;
> > u64 last_rorun;
> > u64 dmiss_max;
> > u64 rorun_max;
> > -};
> > #endif
> > + u64 tot_rtime;
> > +};
> >
>
> I know we agreed to pull this from the sched_param2 structure and delay
> exposing this information for a while until the base patches got merged
> and came up with a solid use-case,
>
Sure! :-)
> but reading this patch makes me
> wonder why tsk->se.sum_exec_runtime isn't good enough?
>
Might be, but what you usually want is something reporting you total
runtime from when you became a -deadline task, which may not be the case
of sum_exec_runtime, is it?
BTW, again, let's postpone this.
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 Fri, 2010-11-12 at 17:15 +0100, Raistlin wrote:
> > but reading this patch makes me
> > wonder why tsk->se.sum_exec_runtime isn't good enough?
> >
> Might be, but what you usually want is something reporting you total
> runtime from when you became a -deadline task, which may not be the case
> of sum_exec_runtime, is it?
Correct, it wouldn't be. However since I expect a user to be mostly
interested in deltas between two readings, in which case it really
doesn't matter, does it?
On Fri, 2010-11-12 at 17:27 +0100, Peter Zijlstra wrote:
> > Might be, but what you usually want is something reporting you total
> > runtime from when you became a -deadline task, which may not be the case
> > of sum_exec_runtime, is it?
>
> Correct, it wouldn't be. However since I expect a user to be mostly
> interested in deltas between two readings, in which case it really
> doesn't matter, does it?
>
Good point. So we won't need this new stat anyway.
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]