[FOR-STABLE-3.9+] sched/rt: Show the 'sched_rr_timeslice' SCHED_RR timeslice tuning knob in milliseconds

[FOR-STABLE-3.9+] sched/rt: Show the 'sched_rr_timeslice' SCHED_RR timeslice tuning knob in milliseconds

[Viresh Kumar]

From: Shile Zhang <shile.zhang@nokia.com>

We added the 'sched_rr_timeslice_ms' SCHED_RR tuning knob in this commit:

  ce0dbbbb30ae ("sched/rt: Add a tuning knob to allow changing SCHED_RR timeslice")

... which name suggests to users that it's in milliseconds, while in reality
it's being set in milliseconds but the result is shown in jiffies.

This is obviously confusing when HZ is not 1000, it makes it appear like the
value set failed, such as HZ=100:

  root# echo 100 > /proc/sys/kernel/sched_rr_timeslice_ms
  root# cat /proc/sys/kernel/sched_rr_timeslice_ms
  10

Fix this to be milliseconds all around.

Cc: <stable@vger.kernel.org> # v3.9+
Signed-off-by: Shile Zhang <shile.zhang@nokia.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/1485612049-20923-1-git-send-email-shile.zhang@nokia.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
---
 include/linux/sched/sysctl.h | 1 +
 kernel/sched/core.c          | 5 +++--
 kernel/sched/rt.c            | 1 +
 kernel/sysctl.c              | 2 +-
 4 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/include/linux/sched/sysctl.h b/include/linux/sched/sysctl.h
index 596a0e007c62..7cae31be37cf 100644
--- a/include/linux/sched/sysctl.h
+++ b/include/linux/sched/sysctl.h
@@ -93,6 +93,7 @@ extern unsigned int sysctl_sched_cfs_bandwidth_slice;
 extern unsigned int sysctl_sched_autogroup_enabled;
 #endif
 
+extern int sysctl_sched_rr_timeslice;
 extern int sched_rr_timeslice;
 
 extern int sched_rr_handler(struct ctl_table *table, int write,
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 45dd606138b0..df6daf7301ee 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -7804,8 +7804,9 @@ int sched_rr_handler(struct ctl_table *table, int write,
 	/* make sure that internally we keep jiffies */
 	/* also, writing zero resets timeslice to default */
 	if (!ret && write) {
-		sched_rr_timeslice = sched_rr_timeslice <= 0 ?
-			RR_TIMESLICE : msecs_to_jiffies(sched_rr_timeslice);
+		sched_rr_timeslice =
+			sysctl_sched_rr_timeslice <= 0 ? RR_TIMESLICE :
+			msecs_to_jiffies(sysctl_sched_rr_timeslice);
 	}
 	mutex_unlock(&mutex);
 	return ret;
diff --git a/kernel/sched/rt.c b/kernel/sched/rt.c
index e0e5b3314c5b..5523766af665 100644
--- a/kernel/sched/rt.c
+++ b/kernel/sched/rt.c
@@ -8,6 +8,7 @@
 #include <linux/slab.h>
 
 int sched_rr_timeslice = RR_TIMESLICE;
+int sysctl_sched_rr_timeslice = (MSEC_PER_SEC / HZ) * RR_TIMESLICE;
 
 static int do_sched_rt_period_timer(struct rt_bandwidth *rt_b, int overrun);
 
diff --git a/kernel/sysctl.c b/kernel/sysctl.c
index c5da3c8a67e8..db51f7b0e7a2 100644
--- a/kernel/sysctl.c
+++ b/kernel/sysctl.c
@@ -421,7 +421,7 @@ static struct ctl_table kern_table[] = {
 	},
 	{
 		.procname	= "sched_rr_timeslice_ms",
-		.data		= &sched_rr_timeslice,
+		.data		= &sysctl_sched_rr_timeslice,
 		.maxlen		= sizeof(int),
 		.mode		= 0644,
 		.proc_handler	= sched_rr_handler,
-- 
2.25.0.rc1.19.g042ed3e048af

Re: [FOR-STABLE-3.9+] sched/rt: Show the 'sched_rr_timeslice' SCHED_RR timeslice tuning knob in milliseconds

[Greg KH]

On Fri, Jul 03, 2020 at 12:54:04PM +0530, Viresh Kumar wrote:
> From: Shile Zhang <shile.zhang@nokia.com>
> 
> We added the 'sched_rr_timeslice_ms' SCHED_RR tuning knob in this commit:
> 
>   ce0dbbbb30ae ("sched/rt: Add a tuning knob to allow changing SCHED_RR timeslice")
> 
> ... which name suggests to users that it's in milliseconds, while in reality
> it's being set in milliseconds but the result is shown in jiffies.
> 
> This is obviously confusing when HZ is not 1000, it makes it appear like the
> value set failed, such as HZ=100:
> 
>   root# echo 100 > /proc/sys/kernel/sched_rr_timeslice_ms
>   root# cat /proc/sys/kernel/sched_rr_timeslice_ms
>   10
> 
> Fix this to be milliseconds all around.
> 
> Cc: <stable@vger.kernel.org> # v3.9+
> Signed-off-by: Shile Zhang <shile.zhang@nokia.com>
> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
> Cc: Linus Torvalds <torvalds@linux-foundation.org>
> Cc: Mike Galbraith <efault@gmx.de>
> Cc: Peter Zijlstra <peterz@infradead.org>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Link: http://lkml.kernel.org/r/1485612049-20923-1-git-send-email-shile.zhang@nokia.com
> Signed-off-by: Ingo Molnar <mingo@kernel.org>
> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>

What is the git commit id of this patch in Linus's tree?

thanks,

greg k-h

Re: [FOR-STABLE-3.9+] sched/rt: Show the 'sched_rr_timeslice' SCHED_RR timeslice tuning knob in milliseconds

[Viresh Kumar]

On 03-07-20, 09:40, Greg KH wrote:
> On Fri, Jul 03, 2020 at 12:54:04PM +0530, Viresh Kumar wrote:
> > From: Shile Zhang <shile.zhang@nokia.com>
> > 
> > We added the 'sched_rr_timeslice_ms' SCHED_RR tuning knob in this commit:
> > 
> >   ce0dbbbb30ae ("sched/rt: Add a tuning knob to allow changing SCHED_RR timeslice")
> > 
> > ... which name suggests to users that it's in milliseconds, while in reality
> > it's being set in milliseconds but the result is shown in jiffies.
> > 
> > This is obviously confusing when HZ is not 1000, it makes it appear like the
> > value set failed, such as HZ=100:
> > 
> >   root# echo 100 > /proc/sys/kernel/sched_rr_timeslice_ms
> >   root# cat /proc/sys/kernel/sched_rr_timeslice_ms
> >   10
> > 
> > Fix this to be milliseconds all around.
> > 
> > Cc: <stable@vger.kernel.org> # v3.9+
> > Signed-off-by: Shile Zhang <shile.zhang@nokia.com>
> > Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
> > Cc: Linus Torvalds <torvalds@linux-foundation.org>
> > Cc: Mike Galbraith <efault@gmx.de>
> > Cc: Peter Zijlstra <peterz@infradead.org>
> > Cc: Thomas Gleixner <tglx@linutronix.de>
> > Link: http://lkml.kernel.org/r/1485612049-20923-1-git-send-email-shile.zhang@nokia.com
> > Signed-off-by: Ingo Molnar <mingo@kernel.org>
> > Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
> 
> What is the git commit id of this patch in Linus's tree?

I am really sorry for missing the only thing I was required to do :(

commit 975e155ed8732cb81f55c021c441ae662dd040b5 upstream.

-- 
viresh

Re: [FOR-STABLE-3.9+] sched/rt: Show the 'sched_rr_timeslice' SCHED_RR timeslice tuning knob in milliseconds

[Sasha Levin]

On Fri, Jul 03, 2020 at 01:13:54PM +0530, Viresh Kumar wrote:
>On 03-07-20, 09:40, Greg KH wrote:
>> On Fri, Jul 03, 2020 at 12:54:04PM +0530, Viresh Kumar wrote:
>> > From: Shile Zhang <shile.zhang@nokia.com>
>> >
>> > We added the 'sched_rr_timeslice_ms' SCHED_RR tuning knob in this commit:
>> >
>> >   ce0dbbbb30ae ("sched/rt: Add a tuning knob to allow changing SCHED_RR timeslice")
>> >
>> > ... which name suggests to users that it's in milliseconds, while in reality
>> > it's being set in milliseconds but the result is shown in jiffies.
>> >
>> > This is obviously confusing when HZ is not 1000, it makes it appear like the
>> > value set failed, such as HZ=100:
>> >
>> >   root# echo 100 > /proc/sys/kernel/sched_rr_timeslice_ms
>> >   root# cat /proc/sys/kernel/sched_rr_timeslice_ms
>> >   10
>> >
>> > Fix this to be milliseconds all around.
>> >
>> > Cc: <stable@vger.kernel.org> # v3.9+
>> > Signed-off-by: Shile Zhang <shile.zhang@nokia.com>
>> > Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
>> > Cc: Linus Torvalds <torvalds@linux-foundation.org>
>> > Cc: Mike Galbraith <efault@gmx.de>
>> > Cc: Peter Zijlstra <peterz@infradead.org>
>> > Cc: Thomas Gleixner <tglx@linutronix.de>
>> > Link: http://lkml.kernel.org/r/1485612049-20923-1-git-send-email-shile.zhang@nokia.com
>> > Signed-off-by: Ingo Molnar <mingo@kernel.org>
>> > Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
>>
>> What is the git commit id of this patch in Linus's tree?
>
>I am really sorry for missing the only thing I was required to do :(
>
>commit 975e155ed8732cb81f55c021c441ae662dd040b5 upstream.

I've queued it for 4.9 and 4.4.

-- 
Thanks,
Sasha