All of lore.kernel.org
 help / color / mirror / Atom feed
* CPU frequency variations
@ 2018-09-10 18:32 Joshi
  2018-09-10 19:00 ` Keith Busch
  2018-09-11  6:55 ` Martin Wilck
  0 siblings, 2 replies; 3+ messages in thread
From: Joshi @ 2018-09-10 18:32 UTC (permalink / raw)


While doing some I/O polling related experiments/optimization, I felt
the need to eliminate fluctuations (in I/O performance) caused by CPU
frequency variations.

During benchmarks (and I mean storage ones), in order to keep running
CPU at nearly constant high frequency, I tried
things such as - performance governor, bios-based performance
settings, explicit setting of sysfs cpu scaling max counters, kernel
parameters to disable cpufreq etc.
Some of above helped; On machines with less number of CPUs. While
nothing seems to help on relatively heavyweight machines.
Such as on this-  Intel Xeon E5-2690 v3 @2.6 GHz, 2 NUMA nodes, 24 cpus each.

Often storage-benchmark seem to suffer because there are more number
of CPUs available; Binding it to single/few CPUs help in seeing better
numbers.

May I know how you deal with CPU frequency variations during benchmarks.

Thanks,
-- 
Joshi

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

* CPU frequency variations
  2018-09-10 18:32 CPU frequency variations Joshi
@ 2018-09-10 19:00 ` Keith Busch
  2018-09-11  6:55 ` Martin Wilck
  1 sibling, 0 replies; 3+ messages in thread
From: Keith Busch @ 2018-09-10 19:00 UTC (permalink / raw)


On Tue, Sep 11, 2018@12:02:25AM +0530, Joshi wrote:
> While doing some I/O polling related experiments/optimization, I felt
> the need to eliminate fluctuations (in I/O performance) caused by CPU
> frequency variations.
> 
> During benchmarks (and I mean storage ones), in order to keep running
> CPU at nearly constant high frequency, I tried
> things such as - performance governor, bios-based performance
> settings, explicit setting of sysfs cpu scaling max counters, kernel
> parameters to disable cpufreq etc.
> Some of above helped; On machines with less number of CPUs. While
> nothing seems to help on relatively heavyweight machines.
> Such as on this-  Intel Xeon E5-2690 v3 @2.6 GHz, 2 NUMA nodes, 24 cpus each.
> 
> Often storage-benchmark seem to suffer because there are more number
> of CPUs available; Binding it to single/few CPUs help in seeing better
> numbers.
> 
> May I know how you deal with CPU frequency variations during benchmarks.

Just to get all the CPU's to use the highest performing scaling
governor:

  echo performance | tee /sys/devices/system/cpu/cpufreq/policy*/scaling_governor

But it sounds like you've alraedy done that.

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

* CPU frequency variations
  2018-09-10 18:32 CPU frequency variations Joshi
  2018-09-10 19:00 ` Keith Busch
@ 2018-09-11  6:55 ` Martin Wilck
  1 sibling, 0 replies; 3+ messages in thread
From: Martin Wilck @ 2018-09-11  6:55 UTC (permalink / raw)


On Tue, 2018-09-11@00:02 +0530, Joshi wrote:
> While doing some I/O polling related experiments/optimization, I felt
> the need to eliminate fluctuations (in I/O performance) caused by CPU
> frequency variations.
> 
> During benchmarks (and I mean storage ones), in order to keep running
> CPU at nearly constant high frequency, I tried
> things such as - performance governor, bios-based performance
> settings, explicit setting of sysfs cpu scaling max counters, kernel
> parameters to disable cpufreq etc.
> Some of above helped; On machines with less number of CPUs. While
> nothing seems to help on relatively heavyweight machines.
> Such as on this-  Intel Xeon E5-2690 v3 @2.6 GHz, 2 NUMA nodes, 24
> cpus each.
> 
> Often storage-benchmark seem to suffer because there are more number
> of CPUs available; Binding it to single/few CPUs help in seeing
> better
> numbers.
> 
> May I know how you deal with CPU frequency variations during
> benchmarks.

Are you certain that it's frequency variations that hurt you? Maybe
your CPUs go to deep sleep states? Have you tried e.g.
"intel_idle.max_cstate=0"?

Martin

-- 
Dr. Martin Wilck <mwilck at suse.com>, Tel. +49 (0)911 74053 2107
SUSE Linux GmbH, GF: Felix Imend?rffer, Jane Smithard, Graham Norton
HRB 21284 (AG N?rnberg)

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

end of thread, other threads:[~2018-09-11  6:55 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-09-10 18:32 CPU frequency variations Joshi
2018-09-10 19:00 ` Keith Busch
2018-09-11  6:55 ` Martin Wilck

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.