SCHED_DEADLINE, sched_getscheduler(), and sched_getparam()

SCHED_DEADLINE, sched_getscheduler(), and sched_getparam()

[Michael Kerrisk (man-pages)]

Hi Peter,

Looking at the code of sched_getparam() and sched_setscheduler() (to
see what might need to land in the man pagea with respect to
SCHED_DEADLINE changes), I see that the former fails (EINVAL) if the
target is a SCHED_DEADLINE process, while the latter succeeds
(returning SCHED_DEADLINE).

The sched_setscheduler() seems fine, but what's the rationale for
having sched_getparam() fail in this case, rather than just returning
a sched_priority of zero (since sched_priority is in any case unused,
as for SCHED_OTHER, right)? My point is that the change seems to
needlessly break applications that employ sched_getparam(). Maybe I am
missing something...

Cheers,

Michael

-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/

Re: SCHED_DEADLINE, sched_getscheduler(), and sched_getparam()

[Peter Zijlstra]

On Mon, May 12, 2014 at 02:09:58PM +0200, Michael Kerrisk (man-pages) wrote:
> Hi Peter,
> 
> Looking at the code of sched_getparam() and sched_setscheduler() (to
> see what might need to land in the man pagea with respect to
> SCHED_DEADLINE changes), I see that the former fails (EINVAL) if the
> target is a SCHED_DEADLINE process, while the latter succeeds
> (returning SCHED_DEADLINE).
> 
> The sched_setscheduler() seems fine, but what's the rationale for
> having sched_getparam() fail in this case, rather than just returning
> a sched_priority of zero (since sched_priority is in any case unused,
> as for SCHED_OTHER, right)? My point is that the change seems to
> needlessly break applications that employ sched_getparam(). Maybe I am
> missing something...

s/setscheduler/getscheduler/ ?

I'm a proponent of fail hard instead of fail silently and muddle on.

And while we can fully and correctly return sched_getscheduler() we
cannot do so for sched_getparam().

Returning sched_param::sched_priority == 0 for DEADLINE would also break
the symmetry between sched_setparam() and sched_getparam(), both will
fail for SCHED_DEADLINE.

Re: SCHED_DEADLINE, sched_getscheduler(), and sched_getparam()

[Michael Kerrisk (man-pages)]

On Mon, May 12, 2014 at 2:24 PM, Peter Zijlstra <peterz@infradead.org> wrote:
> On Mon, May 12, 2014 at 02:09:58PM +0200, Michael Kerrisk (man-pages) wrote:
>> Hi Peter,
>>
>> Looking at the code of sched_getparam() and sched_setscheduler() (to
>> see what might need to land in the man pagea with respect to
>> SCHED_DEADLINE changes), I see that the former fails (EINVAL) if the
>> target is a SCHED_DEADLINE process, while the latter succeeds
>> (returning SCHED_DEADLINE).
>>
>> The sched_setscheduler() seems fine, but what's the rationale for
>> having sched_getparam() fail in this case, rather than just returning
>> a sched_priority of zero (since sched_priority is in any case unused,
>> as for SCHED_OTHER, right)? My point is that the change seems to
>> needlessly break applications that employ sched_getparam(). Maybe I am
>> missing something...
>
> s/setscheduler/getscheduler/ ?

Yes, sorry.

> I'm a proponent of fail hard instead of fail silently and muddle on.
> And while we can fully and correctly return sched_getscheduler() we
> cannot do so for sched_getparam().
>
> Returning sched_param::sched_priority == 0 for DEADLINE would also break
> the symmetry between sched_setparam() and sched_getparam(), both will
> fail for SCHED_DEADLINE.

Maybe. But there seems to me to be a problem with your logic here.
(And the symmetry argument seems a weak one to me.)

I mean, applications that are currently using sched_getscheduler()
will now get back a new policy (SCHED_DEADLINE) that they may not
understand, and so they may break.

On the other hand, applications that call sched_getparam() will fail
with EINVAL, even though sched_priority has no meaning for
SCHED_DEADLINE (as for the non-real-time policies), and so it would
seem to be harmless to succeed and return a sched_priority of 0 in
this case. It seems to break user-space needlessly, IMHO.

If anything, I'd have said it would have made more sense to have the
sched_getscheduler() case fail, while having the sched_getparam() case
succeed. (But, I can see the argument for having _both_ cases
succeed.)

Cheers,

Michael


-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/

Re: SCHED_DEADLINE, sched_getscheduler(), and sched_getparam()

[Peter Zijlstra]

[-- Attachment #1: Type: text/plain, Size: 1913 bytes --]

On Mon, May 12, 2014 at 02:33:42PM +0200, Michael Kerrisk (man-pages) wrote:
> > I'm a proponent of fail hard instead of fail silently and muddle on.
> > And while we can fully and correctly return sched_getscheduler() we
> > cannot do so for sched_getparam().
> >
> > Returning sched_param::sched_priority == 0 for DEADLINE would also break
> > the symmetry between sched_setparam() and sched_getparam(), both will
> > fail for SCHED_DEADLINE.
> 
> Maybe. But there seems to me to be a problem with your logic here.
> (And the symmetry argument seems a weak one to me.)
> 
> I mean, applications that are currently using sched_getscheduler()
> will now get back a new policy (SCHED_DEADLINE) that they may not
> understand, and so they may break.
> 
> On the other hand, applications that call sched_getparam() will fail
> with EINVAL, even though sched_priority has no meaning for
> SCHED_DEADLINE (as for the non-real-time policies), and so it would
> seem to be harmless to succeed and return a sched_priority of 0 in
> this case. It seems to break user-space needlessly, IMHO.
> 
> If anything, I'd have said it would have made more sense to have the
> sched_getscheduler() case fail, while having the sched_getparam() case
> succeed. (But, I can see the argument for having _both_ cases
> succeed.)

Hmm,.. maybe. Can we still change this? Again, maybe, there's not really
that much userspace that relies on this.

In any case, the way I read the little there is on getparam() it seems
to imply the only case where it does make sense to call it at all is
when sched_getscheduler() returns either SCHED_FIFO or SCHED_RR.

And in that sense I suppose the precedent for all other currently
available classes to not fail the param call but return 0 should be
extended.

If only we'd started out with sched_yield()/sched_getparam() etc failing
when not !SCHED_FIFO/RR :-)

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: SCHED_DEADLINE, sched_getscheduler(), and sched_getparam()

[Michael Kerrisk (man-pages)]

On 05/12/2014 05:25 PM, Peter Zijlstra wrote:
> On Mon, May 12, 2014 at 02:33:42PM +0200, Michael Kerrisk (man-pages) wrote:
>>> I'm a proponent of fail hard instead of fail silently and muddle on.
>>> And while we can fully and correctly return sched_getscheduler() we
>>> cannot do so for sched_getparam().
>>>
>>> Returning sched_param::sched_priority == 0 for DEADLINE would also break
>>> the symmetry between sched_setparam() and sched_getparam(), both will
>>> fail for SCHED_DEADLINE.
>>
>> Maybe. But there seems to me to be a problem with your logic here.
>> (And the symmetry argument seems a weak one to me.)
>>
>> I mean, applications that are currently using sched_getscheduler()
>> will now get back a new policy (SCHED_DEADLINE) that they may not
>> understand, and so they may break.
>>
>> On the other hand, applications that call sched_getparam() will fail
>> with EINVAL, even though sched_priority has no meaning for
>> SCHED_DEADLINE (as for the non-real-time policies), and so it would
>> seem to be harmless to succeed and return a sched_priority of 0 in
>> this case. It seems to break user-space needlessly, IMHO.
>>
>> If anything, I'd have said it would have made more sense to have the
>> sched_getscheduler() case fail, while having the sched_getparam() case
>> succeed. (But, I can see the argument for having _both_ cases
>> succeed.)
> 
> Hmm,.. maybe. Can we still change this? Again, maybe, there's not really
> that much userspace that relies on this.

I think the sched_getparam() change is worthwhile (and the patches 
could (should?) be marked for -stable). I suspect there's no user
space that relies on the current SCHED_DEADLINE behavior, and it's 
worth avoiding the above breakage for sched_getparam(). I'd be 
inclined to leave sched_getscheduler() as is: there's arguments 
either way for how it should behave.

> In any case, the way I read the little there is on getparam() it seems
> to imply the only case where it does make sense to call it at all is
> when sched_getscheduler() returns either SCHED_FIFO or SCHED_RR.

(Yes, that's my understanding too.)

> And in that sense I suppose the precedent for all other currently
> available classes to not fail the param call but return 0 should be
> extended.

Yes.

> If only we'd started out with sched_yield()/sched_getparam() etc failing
> when not !SCHED_FIFO/RR :-)

Here, I think we're just following POSIX.

Cheers,

Michael

 


-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/

Re: SCHED_DEADLINE, sched_getscheduler(), and sched_getparam()

[Peter Zijlstra]

On Mon, May 12, 2014 at 09:42:44PM +0200, Michael Kerrisk (man-pages) wrote:
> > Hmm,.. maybe. Can we still change this? Again, maybe, there's not really
> > that much userspace that relies on this.
> 
> I think the sched_getparam() change is worthwhile (and the patches 
> could (should?) be marked for -stable). I suspect there's no user
> space that relies on the current SCHED_DEADLINE behavior, and it's 
> worth avoiding the above breakage for sched_getparam(). I'd be 
> inclined to leave sched_getscheduler() as is: there's arguments 
> either way for how it should behave.
> 
> > In any case, the way I read the little there is on getparam() it seems
> > to imply the only case where it does make sense to call it at all is
> > when sched_getscheduler() returns either SCHED_FIFO or SCHED_RR.
> 
> (Yes, that's my understanding too.)

Something like so then, it encodes that reading explicitly.

---
Subject: sched: Change sched_getparam() behaviour vs SCHED_DEADLINE
From: Peter Zijlstra <peterz@infradead.org>
Date: Mon May 12 22:22:47 CEST 2014

The way we read POSIX one should only call sched_getparam() when
sched_getscheduler() returns either SCHED_FIFO or SCHED_RR.

Given that we currently return sched_param::sched_priority=0 for all
others, extend the same behaviour to SCHED_DEADLINE.

Requested-by: Michael Kerrisk <mtk.manpages@gmail.com>
Signed-off-by: Peter Zijlstra <peterz@infradead.org>
---
 kernel/sched/core.c |    9 +++------
 1 file changed, 3 insertions(+), 6 deletions(-)

Index: linux-2.6/kernel/sched/core.c
===================================================================
--- linux-2.6.orig/kernel/sched/core.c
+++ linux-2.6/kernel/sched/core.c
@@ -3759,7 +3759,7 @@ SYSCALL_DEFINE1(sched_getscheduler, pid_
  */
 SYSCALL_DEFINE2(sched_getparam, pid_t, pid, struct sched_param __user *, param)
 {
-	struct sched_param lp;
+	struct sched_param lp = { .sched_priority = 0 };
 	struct task_struct *p;
 	int retval;
 
@@ -3776,11 +3776,8 @@ SYSCALL_DEFINE2(sched_getparam, pid_t, p
 	if (retval)
 		goto out_unlock;
 
-	if (task_has_dl_policy(p)) {
-		retval = -EINVAL;
-		goto out_unlock;
-	}
-	lp.sched_priority = p->rt_priority;
+	if (task_has_rt_policy(p))
+		lp.sched_priority = p->rt_priority;
 	rcu_read_unlock();
 
 	/*

[tip:sched/core] peter_zijlstra-sched-change_sched_getparam_behaviour_vs_sched_deadline

[tip-bot for Peter Zijlstra]

Commit-ID:  339d8f7bbf4a54fc09650b24ce505a4c04236bb3
Gitweb:     http://git.kernel.org/tip/339d8f7bbf4a54fc09650b24ce505a4c04236bb3
Author:     Peter Zijlstra <peterz@infradead.org>
AuthorDate: Mon, 12 May 2014 22:50:34 +0200
Committer:  Thomas Gleixner <tglx@linutronix.de>
CommitDate: Mon, 19 May 2014 21:47:33 +0900

peter_zijlstra-sched-change_sched_getparam_behaviour_vs_sched_deadline

The way we read POSIX one should only call sched_getparam() when
sched_getscheduler() returns either SCHED_FIFO or SCHED_RR.

Given that we currently return sched_param::sched_priority=0 for all
others, extend the same behaviour to SCHED_DEADLINE.

Cc: stable@vger.kernel.org
Cc: Dario Faggioli <raistlin@linux.it>
Cc: linux-man <linux-man@vger.kernel.org>
Cc: "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com>
Cc: Juri Lelli <juri.lelli@gmail.com>
Requested-by: Michael Kerrisk <mtk.manpages@gmail.com>
Acked-by: Michael Kerrisk <mtk.manpages@gmail.com>
Signed-off-by: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/20140512205034.GH13467@laptop.programming.kicks-ass.net
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
---
 kernel/sched/core.c | 9 +++------
 1 file changed, 3 insertions(+), 6 deletions(-)

diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index cdefcf7..f3f08bf 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -3713,7 +3713,7 @@ SYSCALL_DEFINE1(sched_getscheduler, pid_t, pid)
  */
 SYSCALL_DEFINE2(sched_getparam, pid_t, pid, struct sched_param __user *, param)
 {
-	struct sched_param lp;
+	struct sched_param lp = { .sched_priority = 0 };
 	struct task_struct *p;
 	int retval;
 
@@ -3730,11 +3730,8 @@ SYSCALL_DEFINE2(sched_getparam, pid_t, pid, struct sched_param __user *, param)
 	if (retval)
 		goto out_unlock;
 
-	if (task_has_dl_policy(p)) {
-		retval = -EINVAL;
-		goto out_unlock;
-	}
-	lp.sched_priority = p->rt_priority;
+	if (task_has_rt_policy(p))
+		lp.sched_priority = p->rt_priority;
 	rcu_read_unlock();
 
 	/*

[tip:sched/core] sched/deadline: Change sched_getparam() behaviour vs SCHED_DEADLINE

[tip-bot for Peter Zijlstra]

Commit-ID:  ce5f7f8200ca2504f6f290044393d73ca314965a
Gitweb:     http://git.kernel.org/tip/ce5f7f8200ca2504f6f290044393d73ca314965a
Author:     Peter Zijlstra <peterz@infradead.org>
AuthorDate: Mon, 12 May 2014 22:50:34 +0200
Committer:  Ingo Molnar <mingo@kernel.org>
CommitDate: Thu, 22 May 2014 10:21:26 +0200

sched/deadline: Change sched_getparam() behaviour vs SCHED_DEADLINE

The way we read POSIX one should only call sched_getparam() when
sched_getscheduler() returns either SCHED_FIFO or SCHED_RR.

Given that we currently return sched_param::sched_priority=0 for all
others, extend the same behaviour to SCHED_DEADLINE.

Requested-by: Michael Kerrisk <mtk.manpages@gmail.com>
Signed-off-by: Peter Zijlstra <peterz@infradead.org>
Acked-by: Michael Kerrisk <mtk.manpages@gmail.com>
Cc: Dario Faggioli <raistlin@linux.it>
Cc: linux-man <linux-man@vger.kernel.org>
Cc: "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com>
Cc: Juri Lelli <juri.lelli@gmail.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: <stable@vger.kernel.org>
Link: http://lkml.kernel.org/r/20140512205034.GH13467@laptop.programming.kicks-ass.net
Signed-off-by: Ingo Molnar <mingo@kernel.org>
---
 kernel/sched/core.c | 9 +++------
 1 file changed, 3 insertions(+), 6 deletions(-)

diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index cdefcf7..f3f08bf 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -3713,7 +3713,7 @@ SYSCALL_DEFINE1(sched_getscheduler, pid_t, pid)
  */
 SYSCALL_DEFINE2(sched_getparam, pid_t, pid, struct sched_param __user *, param)
 {
-	struct sched_param lp;
+	struct sched_param lp = { .sched_priority = 0 };
 	struct task_struct *p;
 	int retval;
 
@@ -3730,11 +3730,8 @@ SYSCALL_DEFINE2(sched_getparam, pid_t, pid, struct sched_param __user *, param)
 	if (retval)
 		goto out_unlock;
 
-	if (task_has_dl_policy(p)) {
-		retval = -EINVAL;
-		goto out_unlock;
-	}
-	lp.sched_priority = p->rt_priority;
+	if (task_has_rt_policy(p))
+		lp.sched_priority = p->rt_priority;
 	rcu_read_unlock();
 
 	/*