All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com>
Cc: Juri Lelli <juri.lelli@gmail.com>,
	Dario Faggioli <raistlin@linux.it>,
	lkml <linux-kernel@vger.kernel.org>,
	linux-man <linux-man@vger.kernel.org>
Subject: Re: SCHED_DEADLINE, sched_getscheduler(), and sched_getparam()
Date: Mon, 12 May 2014 22:50:34 +0200	[thread overview]
Message-ID: <20140512205034.GH13467@laptop.programming.kicks-ass.net> (raw)
In-Reply-To: <53712434.2060705@gmail.com>

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();
 
 	/*

WARNING: multiple messages have this Message-ID (diff)
From: Peter Zijlstra <peterz-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
To: "Michael Kerrisk (man-pages)"
	<mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: Juri Lelli <juri.lelli-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
	Dario Faggioli <raistlin-k2GhghHVRtY@public.gmane.org>,
	lkml <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	linux-man <linux-man-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Subject: Re: SCHED_DEADLINE, sched_getscheduler(), and sched_getparam()
Date: Mon, 12 May 2014 22:50:34 +0200	[thread overview]
Message-ID: <20140512205034.GH13467@laptop.programming.kicks-ass.net> (raw)
In-Reply-To: <53712434.2060705-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>

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

  reply	other threads:[~2014-05-12 20:50 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
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)

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140512205034.GH13467@laptop.programming.kicks-ass.net \
    --to=peterz@infradead.org \
    --cc=juri.lelli@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-man@vger.kernel.org \
    --cc=mtk.manpages@gmail.com \
    --cc=raistlin@linux.it \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.