[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 11 Nov 2010 20:37:03 +0100
From: Peter Zijlstra <peterz@...radead.org>
To: Raistlin <raistlin@...ux.it>
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 12/22] sched: add runtime reporting for -deadline
tasks
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 <raistlin@...ux.it>
> ---
> 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?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists