* SCHED_DEADLINE, sched_getscheduler(), and sched_getparam()
@ 2014-05-12 12:09 ` Michael Kerrisk (man-pages)
0 siblings, 0 replies; 14+ messages in thread
From: Michael Kerrisk (man-pages) @ 2014-05-12 12:09 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Juri Lelli, Dario Faggioli, lkml, linux-man, Michael Kerrisk
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/
^ permalink raw reply [flat|nested] 14+ messages in thread
* SCHED_DEADLINE, sched_getscheduler(), and sched_getparam()
@ 2014-05-12 12:09 ` Michael Kerrisk (man-pages)
0 siblings, 0 replies; 14+ messages in thread
From: Michael Kerrisk (man-pages) @ 2014-05-12 12:09 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Juri Lelli, Dario Faggioli, lkml, linux-man, Michael Kerrisk
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/
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: SCHED_DEADLINE, sched_getscheduler(), and sched_getparam()
@ 2014-05-12 12:24 ` Peter Zijlstra
0 siblings, 0 replies; 14+ messages in thread
From: Peter Zijlstra @ 2014-05-12 12:24 UTC (permalink / raw)
To: Michael Kerrisk (man-pages); +Cc: Juri Lelli, Dario Faggioli, lkml, linux-man
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.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: SCHED_DEADLINE, sched_getscheduler(), and sched_getparam()
@ 2014-05-12 12:24 ` Peter Zijlstra
0 siblings, 0 replies; 14+ messages in thread
From: Peter Zijlstra @ 2014-05-12 12:24 UTC (permalink / raw)
To: Michael Kerrisk (man-pages); +Cc: Juri Lelli, Dario Faggioli, lkml, linux-man
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.
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: SCHED_DEADLINE, sched_getscheduler(), and sched_getparam()
2014-05-12 12:24 ` Peter Zijlstra
(?)
@ 2014-05-12 12:33 ` Michael Kerrisk (man-pages)
2014-05-12 15:25 ` Peter Zijlstra
-1 siblings, 1 reply; 14+ messages in thread
From: Michael Kerrisk (man-pages) @ 2014-05-12 12:33 UTC (permalink / raw)
To: Peter Zijlstra; +Cc: Juri Lelli, Dario Faggioli, lkml, linux-man
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/
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: SCHED_DEADLINE, sched_getscheduler(), and sched_getparam()
2014-05-12 12:33 ` Michael Kerrisk (man-pages)
@ 2014-05-12 15:25 ` Peter Zijlstra
2014-05-12 19:42 ` Michael Kerrisk (man-pages)
0 siblings, 1 reply; 14+ messages in thread
From: Peter Zijlstra @ 2014-05-12 15:25 UTC (permalink / raw)
To: Michael Kerrisk (man-pages); +Cc: Juri Lelli, Dario Faggioli, lkml, linux-man
[-- 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 --]
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: SCHED_DEADLINE, sched_getscheduler(), and sched_getparam()
@ 2014-05-12 19:42 ` Michael Kerrisk (man-pages)
0 siblings, 0 replies; 14+ messages in thread
From: Michael Kerrisk (man-pages) @ 2014-05-12 19:42 UTC (permalink / raw)
To: Peter Zijlstra; +Cc: mtk.manpages, Juri Lelli, Dario Faggioli, lkml, linux-man
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/
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: SCHED_DEADLINE, sched_getscheduler(), and sched_getparam()
@ 2014-05-12 19:42 ` Michael Kerrisk (man-pages)
0 siblings, 0 replies; 14+ messages in thread
From: Michael Kerrisk (man-pages) @ 2014-05-12 19:42 UTC (permalink / raw)
To: Peter Zijlstra
Cc: mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w, Juri Lelli, Dario Faggioli,
lkml, linux-man
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/
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: SCHED_DEADLINE, sched_getscheduler(), and sched_getparam()
@ 2014-05-12 20:50 ` Peter Zijlstra
0 siblings, 0 replies; 14+ messages in thread
From: Peter Zijlstra @ 2014-05-12 20:50 UTC (permalink / raw)
To: Michael Kerrisk (man-pages); +Cc: Juri Lelli, Dario Faggioli, lkml, linux-man
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();
/*
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: SCHED_DEADLINE, sched_getscheduler(), and sched_getparam()
@ 2014-05-12 20:50 ` Peter Zijlstra
0 siblings, 0 replies; 14+ messages in thread
From: Peter Zijlstra @ 2014-05-12 20:50 UTC (permalink / raw)
To: Michael Kerrisk (man-pages); +Cc: Juri Lelli, Dario Faggioli, lkml, linux-man
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-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.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-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Signed-off-by: Peter Zijlstra <peterz-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.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();
/*
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 14+ messages in thread
* [tip:sched/core] peter_zijlstra-sched-change_sched_getparam_behaviour_vs_sched_deadline
2014-05-12 20:50 ` Peter Zijlstra
(?)
@ 2014-05-19 13:06 ` tip-bot for Peter Zijlstra
-1 siblings, 0 replies; 14+ messages in thread
From: tip-bot for Peter Zijlstra @ 2014-05-19 13:06 UTC (permalink / raw)
To: linux-tip-commits
Cc: linux-kernel, hpa, mingo, peterz, raistlin, linux-man, tglx,
mtk.manpages, juri.lelli
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();
/*
^ permalink raw reply related [flat|nested] 14+ messages in thread
* [tip:sched/core] sched/deadline: Change sched_getparam() behaviour vs SCHED_DEADLINE
2014-05-12 20:50 ` Peter Zijlstra
(?)
(?)
@ 2014-05-22 12:25 ` tip-bot for Peter Zijlstra
-1 siblings, 0 replies; 14+ messages in thread
From: tip-bot for Peter Zijlstra @ 2014-05-22 12:25 UTC (permalink / raw)
To: linux-tip-commits
Cc: linux-kernel, hpa, mingo, torvalds, peterz, stable, raistlin,
linux-man, tglx, mtk.manpages, juri.lelli
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();
/*
^ permalink raw reply related [flat|nested] 14+ messages in thread
* Re: SCHED_DEADLINE, sched_getscheduler(), and sched_getparam()
@ 2014-05-13 8:14 ` Michael Kerrisk (man-pages)
0 siblings, 0 replies; 14+ messages in thread
From: Michael Kerrisk (man-pages) @ 2014-05-13 8:14 UTC (permalink / raw)
To: Peter Zijlstra; +Cc: Juri Lelli, Dario Faggioli, lkml, linux-man
On Mon, May 12, 2014 at 10:50 PM, Peter Zijlstra <peterz@infradead.org> wrote:
> 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.
Seems reasonable to me.
Acked-by: Michael Kerrisk <mtk.manpages@gmail.com>
Thanks,
Michael
> ---
> 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();
>
> /*
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: SCHED_DEADLINE, sched_getscheduler(), and sched_getparam()
@ 2014-05-13 8:14 ` Michael Kerrisk (man-pages)
0 siblings, 0 replies; 14+ messages in thread
From: Michael Kerrisk (man-pages) @ 2014-05-13 8:14 UTC (permalink / raw)
To: Peter Zijlstra; +Cc: Juri Lelli, Dario Faggioli, lkml, linux-man
On Mon, May 12, 2014 at 10:50 PM, Peter Zijlstra <peterz-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org> wrote:
> 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.
Seems reasonable to me.
Acked-by: Michael Kerrisk <mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Thanks,
Michael
> ---
> Subject: sched: Change sched_getparam() behaviour vs SCHED_DEADLINE
> From: Peter Zijlstra <peterz-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.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-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Signed-off-by: Peter Zijlstra <peterz-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.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();
>
> /*
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2014-05-22 12:26 UTC | newest]
Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-05-12 12:09 SCHED_DEADLINE, sched_getscheduler(), and sched_getparam() Michael Kerrisk (man-pages)
2014-05-12 12:09 ` Michael Kerrisk (man-pages)
2014-05-12 12:24 ` Peter Zijlstra
2014-05-12 12:24 ` Peter Zijlstra
2014-05-12 12:33 ` Michael Kerrisk (man-pages)
2014-05-12 15:25 ` Peter Zijlstra
2014-05-12 19:42 ` Michael Kerrisk (man-pages)
2014-05-12 19:42 ` Michael Kerrisk (man-pages)
2014-05-12 20:50 ` Peter Zijlstra
2014-05-12 20:50 ` Peter Zijlstra
2014-05-19 13:06 ` [tip:sched/core] peter_zijlstra-sched-change_sched_getparam_behaviour_vs_sched_deadline tip-bot for Peter Zijlstra
2014-05-22 12:25 ` [tip:sched/core] sched/deadline: Change sched_getparam() behaviour vs SCHED_DEADLINE tip-bot for Peter Zijlstra
2014-05-13 8:14 SCHED_DEADLINE, sched_getscheduler(), and sched_getparam() Michael Kerrisk (man-pages)
2014-05-13 8:14 ` Michael Kerrisk (man-pages)
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.