linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH RFC] rcuperf: make timeout HZ independent
@ 2016-08-22 11:21 Nicholas Mc Guire
  2016-08-22 11:49 ` Paul E. McKenney
  0 siblings, 1 reply; 3+ messages in thread
From: Nicholas Mc Guire @ 2016-08-22 11:21 UTC (permalink / raw)
  To: Paul E. McKenney
  Cc: Josh Triplett, Steven Rostedt, Mathieu Desnoyers, Lai Jiangshan,
	linux-kernel, Nicholas Mc Guire

Make the probability of ftrace dump not interfering with other writers 
grace period, HZ independent.

Signed-off-by: Nicholas Mc Guire <hofrat@osadl.org>
---

Problem found by coccinelle script

Passing in jiffies as value allows for this "fixed" delay varying by 
one order of magnitude. As it is intended to reduce the probability of 
interference this probability should not be dependent on the systems 
HZ setting. Its probably more cosmetic but I guess this is the cleaner
way for fixed delays.

Q: Could not really figure out why the _interruptible_ version is used
   here - I would assume that schedule_timeout() would be what is needed
   here, as this should simply be a fixed delay.

Patch was compile tested with: x86_64_defconfig + CONFIG_RCU_PERF_TEST=m

Patch is against 4.8.0-rc2 (localversion-next is -next-20160822)

 kernel/rcu/rcuperf.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/kernel/rcu/rcuperf.c b/kernel/rcu/rcuperf.c
index 123ccbd..4cd8655 100644
--- a/kernel/rcu/rcuperf.c
+++ b/kernel/rcu/rcuperf.c
@@ -404,7 +404,8 @@ rcu_perf_writer(void *arg)
 				 perf_type, PERF_FLAG, me, MIN_MEAS);
 			if (atomic_inc_return(&n_rcu_perf_writer_finished) >=
 			    nrealwriters) {
-				schedule_timeout_interruptible(10);
+				schedule_timeout_interruptible(
+							msecs_to_jiffies(10));
 				rcu_ftrace_dump(DUMP_ALL);
 				PERFOUT_STRING("Test complete");
 				t_rcu_perf_writer_finished = t;
-- 
2.1.4

^ permalink raw reply related	[flat|nested] 3+ messages in thread

* Re: [PATCH RFC] rcuperf: make timeout HZ independent
  2016-08-22 11:21 [PATCH RFC] rcuperf: make timeout HZ independent Nicholas Mc Guire
@ 2016-08-22 11:49 ` Paul E. McKenney
  2016-08-22 12:19   ` Nicholas Mc Guire
  0 siblings, 1 reply; 3+ messages in thread
From: Paul E. McKenney @ 2016-08-22 11:49 UTC (permalink / raw)
  To: Nicholas Mc Guire
  Cc: Josh Triplett, Steven Rostedt, Mathieu Desnoyers, Lai Jiangshan,
	linux-kernel

On Mon, Aug 22, 2016 at 01:21:05PM +0200, Nicholas Mc Guire wrote:
> Make the probability of ftrace dump not interfering with other writers 
> grace period, HZ independent.
> 
> Signed-off-by: Nicholas Mc Guire <hofrat@osadl.org>

What we would -really- like is to vary the time based on the clock rate
of the CPUs (could use bogomips, I suppose) and the memory latency of
the system, so that systems with smaller memory latency and faster CPUs
would use shorter timeouts.  However, slower CPUs tend to use smaller
HZ values, so varying based on HZ is not entirely insane.

But what would you suggest?

Good question on schedule_timeout_interruptible()...  I usually do that
if there is some reason to be sensitive to an early wakeup, for example,
to allow shutdown to proceed quickly, but that doesn't make much sense
here, given that ftrace_dump() is likely to take a very long time.

							Thanx, Paul

> ---
> 
> Problem found by coccinelle script
> 
> Passing in jiffies as value allows for this "fixed" delay varying by 
> one order of magnitude. As it is intended to reduce the probability of 
> interference this probability should not be dependent on the systems 
> HZ setting. Its probably more cosmetic but I guess this is the cleaner
> way for fixed delays.
> 
> Q: Could not really figure out why the _interruptible_ version is used
>    here - I would assume that schedule_timeout() would be what is needed
>    here, as this should simply be a fixed delay.
> 
> Patch was compile tested with: x86_64_defconfig + CONFIG_RCU_PERF_TEST=m
> 
> Patch is against 4.8.0-rc2 (localversion-next is -next-20160822)
> 
>  kernel/rcu/rcuperf.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/kernel/rcu/rcuperf.c b/kernel/rcu/rcuperf.c
> index 123ccbd..4cd8655 100644
> --- a/kernel/rcu/rcuperf.c
> +++ b/kernel/rcu/rcuperf.c
> @@ -404,7 +404,8 @@ rcu_perf_writer(void *arg)
>  				 perf_type, PERF_FLAG, me, MIN_MEAS);
>  			if (atomic_inc_return(&n_rcu_perf_writer_finished) >=
>  			    nrealwriters) {
> -				schedule_timeout_interruptible(10);
> +				schedule_timeout_interruptible(
> +							msecs_to_jiffies(10));
>  				rcu_ftrace_dump(DUMP_ALL);
>  				PERFOUT_STRING("Test complete");
>  				t_rcu_perf_writer_finished = t;
> -- 
> 2.1.4
> 

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [PATCH RFC] rcuperf: make timeout HZ independent
  2016-08-22 11:49 ` Paul E. McKenney
@ 2016-08-22 12:19   ` Nicholas Mc Guire
  0 siblings, 0 replies; 3+ messages in thread
From: Nicholas Mc Guire @ 2016-08-22 12:19 UTC (permalink / raw)
  To: Paul E. McKenney
  Cc: Nicholas Mc Guire, Josh Triplett, Steven Rostedt,
	Mathieu Desnoyers, Lai Jiangshan, linux-kernel

On Mon, Aug 22, 2016 at 04:49:43AM -0700, Paul E. McKenney wrote:
> On Mon, Aug 22, 2016 at 01:21:05PM +0200, Nicholas Mc Guire wrote:
> > Make the probability of ftrace dump not interfering with other writers 
> > grace period, HZ independent.
> > 
> > Signed-off-by: Nicholas Mc Guire <hofrat@osadl.org>
> 
> What we would -really- like is to vary the time based on the clock rate
> of the CPUs (could use bogomips, I suppose) and the memory latency of
> the system, so that systems with smaller memory latency and faster CPUs
> would use shorter timeouts.  However, slower CPUs tend to use smaller
> HZ values, so varying based on HZ is not entirely insane.
> 
> But what would you suggest?

so what you want is a rough estimate of a "fixed instruction quantum"
while bogomips/cpu_khz would ignore memory latency it might still be
better than a fixed time then - something like 
  schedule_timeout(msecs_to_jiffies(10000/cpu_khz)); ?

> 
> Good question on schedule_timeout_interruptible()...  I usually do that
> if there is some reason to be sensitive to an early wakeup, for example,
> to allow shutdown to proceed quickly, but that doesn't make much sense
> here, given that ftrace_dump() is likely to take a very long time.
>
ok - just though that I was overlooking something - thanks for the 
clarification.

thx!
hofrat 

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2016-08-22 12:20 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-08-22 11:21 [PATCH RFC] rcuperf: make timeout HZ independent Nicholas Mc Guire
2016-08-22 11:49 ` Paul E. McKenney
2016-08-22 12:19   ` Nicholas Mc Guire

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).