Hi all,
this is a tiny patch providing readings of the current (leftover)
runtime and absolute deadline in /proc/*/sched. Mostly useful for
debugging, I heard others playing with SCHED_DEADLINE had some need
for similar patches as well.
In addition to debugging, reading the leftover runtime is generally
useful for adaptive/incremental RT logics that need to check whether
there's enough runtime left for refining the computed result, or just
use what we've computed so far and block till the next instance.
Also, knowing what the absolute scheduling deadline is (along with
what clock it refers to) might be useful for synchronization purposes.
(albeit, for real production code, I wouldn't like to parse /proc anyway,
rather I'd prefer to retrieve those params via eg sched_getscheduler()?)
Please, share your thoughts, thanks.
Tommaso
From: Tommaso Cucinotta <[email protected]>
---
kernel/sched/debug.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/kernel/sched/debug.c b/kernel/sched/debug.c
index fa178b6..109adc0 100644
--- a/kernel/sched/debug.c
+++ b/kernel/sched/debug.c
@@ -953,6 +953,10 @@ void proc_sched_show_task(struct task_struct *p, struct seq_file *m)
#endif
P(policy);
P(prio);
+ if (p->policy == SCHED_DEADLINE) {
+ P(dl.runtime);
+ P(dl.deadline);
+ }
#undef PN_SCHEDSTAT
#undef PN
#undef __PN
--
2.7.4
On Tue, Oct 25, 2016 at 12:32:53AM +0200, Tommaso Cucinotta wrote:
> Hi all,
>
> this is a tiny patch providing readings of the current (leftover)
> runtime and absolute deadline in /proc/*/sched. Mostly useful for
> debugging, I heard others playing with SCHED_DEADLINE had some need
> for similar patches as well.
>
> In addition to debugging, reading the leftover runtime is generally
> useful for adaptive/incremental RT logics that need to check whether
> there's enough runtime left for refining the computed result, or just
> use what we've computed so far and block till the next instance.
> Also, knowing what the absolute scheduling deadline is (along with
> what clock it refers to) might be useful for synchronization purposes.
> (albeit, for real production code, I wouldn't like to parse /proc anyway,
> rather I'd prefer to retrieve those params via eg sched_getscheduler()?)
So for programmatic use, this interface is not recommended. For
debugging this is fine.
Not sure what form the programmatic interface should take, we have
precedence in sys_sched_rr_get_interval() for a syscall (we could even
abuse this one).
Anybody any ideas?
On 25/10/16 11:25, Peter Zijlstra wrote:
> On Tue, Oct 25, 2016 at 12:32:53AM +0200, Tommaso Cucinotta wrote:
> > Hi all,
> >
> > this is a tiny patch providing readings of the current (leftover)
> > runtime and absolute deadline in /proc/*/sched. Mostly useful for
> > debugging, I heard others playing with SCHED_DEADLINE had some need
> > for similar patches as well.
> >
> > In addition to debugging, reading the leftover runtime is generally
> > useful for adaptive/incremental RT logics that need to check whether
> > there's enough runtime left for refining the computed result, or just
> > use what we've computed so far and block till the next instance.
> > Also, knowing what the absolute scheduling deadline is (along with
> > what clock it refers to) might be useful for synchronization purposes.
> > (albeit, for real production code, I wouldn't like to parse /proc anyway,
> > rather I'd prefer to retrieve those params via eg sched_getscheduler()?)
>
> So for programmatic use, this interface is not recommended. For
> debugging this is fine.
>
> Not sure what form the programmatic interface should take, we have
> precedence in sys_sched_rr_get_interval() for a syscall (we could even
> abuse this one).
>
> Anybody any ideas?
>
Maybe extend getattr() to return actual runtime params? (instead of the
static ones, or along to them)
Hi,
On 25/10/16 00:32, Tommaso Cucinotta wrote:
> From: Tommaso Cucinotta <[email protected]>
You should probably commit from your sssup address?
Also changelog is missing. You can simply put here part of your cover
letter wordings.
>
> ---
> kernel/sched/debug.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/kernel/sched/debug.c b/kernel/sched/debug.c
> index fa178b6..109adc0 100644
> --- a/kernel/sched/debug.c
> +++ b/kernel/sched/debug.c
> @@ -953,6 +953,10 @@ void proc_sched_show_task(struct task_struct *p, struct seq_file *m)
> #endif
> P(policy);
> P(prio);
> + if (p->policy == SCHED_DEADLINE) {
> + P(dl.runtime);
> + P(dl.deadline);
> + }
For testing purposes looks ok to me.
Best,
- Juri
On Tue, 25 Oct 2016 10:33:21 +0100
Juri Lelli <[email protected]> wrote:
> On 25/10/16 11:25, Peter Zijlstra wrote:
> > On Tue, Oct 25, 2016 at 12:32:53AM +0200, Tommaso Cucinotta wrote:
> > > Hi all,
> > >
> > > this is a tiny patch providing readings of the current (leftover)
> > > runtime and absolute deadline in /proc/*/sched. Mostly useful for
> > > debugging, I heard others playing with SCHED_DEADLINE had some
> > > need for similar patches as well.
> > >
> > > In addition to debugging, reading the leftover runtime is
> > > generally useful for adaptive/incremental RT logics that need to
> > > check whether there's enough runtime left for refining the
> > > computed result, or just use what we've computed so far and block
> > > till the next instance. Also, knowing what the absolute
> > > scheduling deadline is (along with what clock it refers to) might
> > > be useful for synchronization purposes. (albeit, for real
> > > production code, I wouldn't like to parse /proc anyway, rather
> > > I'd prefer to retrieve those params via eg
> > > sched_getscheduler()?)
> >
> > So for programmatic use, this interface is not recommended. For
> > debugging this is fine.
> >
> > Not sure what form the programmatic interface should take, we have
> > precedence in sys_sched_rr_get_interval() for a syscall (we could
> > even abuse this one).
> >
> > Anybody any ideas?
> >
>
> Maybe extend getattr() to return actual runtime params? (instead of
> the static ones, or along to them)
This is similar to what I did in the past: I used (or maybe abused?)
the "flags" argument of getattr() to tell it if I wanted it to return
the current runtime and scheduling deadline, or the maximum runtime and
relative deadline.
I think that both the "/proc based" interface proposed by Tommaso and
the syscall-based one are useful (for different purposes).
Luca
Il 25/10/2016 12:10, luca abeni ha scritto:
> I think that both the "/proc based" interface proposed by Tommaso and
> the syscall-based one are useful (for different purposes).
+1
-- Daniel
This patch allows for reading the current (leftover) runtime and
absolute deadline in /proc/*/sched, for debugging purposes.
This revised patch:
1) has a fixed format, Signed-off-by, etc., as suggested by Juri
2) now includes related docs in Documentation/
3) now I'm sending these e-mails with the correct From:
[PATCH] sched/deadline: show leftover runtime and abs deadline in
Thanks,
T.
--
Hi all,
this is a tiny patch providing readings of the current (leftover)
runtime and absolute deadline in /proc/*/sched. Mostly useful for
debugging, I heard others playing with SCHED_DEADLINE had some need
for similar patches as well.
In addition to debugging, reading the leftover runtime is generally
useful for adaptive/incremental RT logics that need to check whether
there's enough runtime left for refining the computed result, or just
use what we've computed so far and block till the next instance.
Also, knowing what the absolute scheduling deadline is (along with
what clock it refers to) might be useful for synchronization purposes.
(albeit, for real production code, I wouldn't like to parse /proc anyway,
rather I'd prefer to retrieve those params via eg sched_getscheduler()?)
This patch allows for reading the current (leftover) runtime and
absolute deadline of a SCHED_DEADLINE task through /proc/*/sched
(entries dl.runtime and dl.deadline), while debugging/testing.
Signed-off-by: Tommaso Cucinotta <[email protected]>
Reviewed-by: Juri Lelli <[email protected]>
Reviewed-by: Luca Abeni <[email protected]>
Acked-by: Daniel Bistrot de Oliveira <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Cc: Ingo Molnar <[email protected]>
---
Documentation/scheduler/sched-deadline.txt | 6 ++++++
kernel/sched/debug.c | 4 ++++
2 files changed, 10 insertions(+)
diff --git a/Documentation/scheduler/sched-deadline.txt b/Documentation/scheduler/sched-deadline.txt
index 8e37b0b..cbc1b46 100644
--- a/Documentation/scheduler/sched-deadline.txt
+++ b/Documentation/scheduler/sched-deadline.txt
@@ -408,6 +408,11 @@ CONTENTS
* the new scheduling related syscalls that manipulate it, i.e.,
sched_setattr() and sched_getattr() are implemented.
+ For debugging purposes, the leftover runtime and absolute deadline of a
+ SCHED_DEADLINE task can be retrieved through /proc/<pid>/sched (entries
+ dl.runtime and dl.deadline, both values in ns). A programmatic way to
+ retrieve these values from production code is under discussion.
+
4.3 Default behavior
---------------------
@@ -476,6 +481,7 @@ CONTENTS
Still missing:
+ - programmatic way to retrieve current runtime and absolute deadline
- refinements to deadline inheritance, especially regarding the possibility
of retaining bandwidth isolation among non-interacting tasks. This is
being studied from both theoretical and practical points of view, and
diff --git a/kernel/sched/debug.c b/kernel/sched/debug.c
index fa178b6..109adc0 100644
--- a/kernel/sched/debug.c
+++ b/kernel/sched/debug.c
@@ -953,6 +953,10 @@ void proc_sched_show_task(struct task_struct *p, struct seq_file *m)
#endif
P(policy);
P(prio);
+ if (p->policy == SCHED_DEADLINE) {
+ P(dl.runtime);
+ P(dl.deadline);
+ }
#undef PN_SCHEDSTAT
#undef PN
#undef __PN
--
2.7.4