Skip to contentSkip to conversation

scheduling latency & CONFIG_HZ

DISCUSSION Tim Blechmann 3 participants 4 messages Nov 11, 2009 – Nov 21, 2009

lore
Share & tools
lore

Tim Blechmann

author
#0 lore raw

i am curious, do the values of CONFIG_HZ and CONFIG_NO_HZ somehow affect the scheduling latency (as reported by cyclictest) of a real-time/vanilla kernel, especially when CONFIG_HIGH_RES_TIMERS is enabled?

thnx, tim

Signature · 6 lines
[email protected]
http://tim.klingt.org

The price an artist pays for doing what he wants is that he has to do
it.
  William S. Burroughs
#1 lore raw
Quoted 3 lines · Tim Blechmann

i am curious, do the values of CONFIG_HZ and CONFIG_NO_HZ somehow affect the scheduling latency (as reported by cyclictest) of a real-time/vanilla kernel, especially when CONFIG_HIGH_RES_TIMERS is enabled?

CONFIG_HZ should be pretty irrelevant, but CONFIG_NO_HZ=y especially when the CPU does support deeper C-States and the ACPI cpuidle support is active may influence it simply because the wake up from deeper c-states can take significantly longer than waking up from C1 (the default halt state). Note that the wakeup latency from C-States depends on the CPU model, chipset, available timer hardware ...

Thanks,

tglx

author
#2 lore raw
Quoted 10 lines
Quoted 3 lines

i am curious, do the values of CONFIG_HZ and CONFIG_NO_HZ somehow affect the scheduling latency (as reported by cyclictest) of a real-time/vanilla kernel, especially when CONFIG_HIGH_RES_TIMERS is enabled?

CONFIG_HZ should be pretty irrelevant, but CONFIG_NO_HZ=y especially when the CPU does support deeper C-States and the ACPI cpuidle support is active may influence it simply because the wake up from deeper c-states can take significantly longer than waking up from C1 (the default halt state). Note that the wakeup latency from C-States depends on the CPU model, chipset, available timer hardware ...

interesting ... from my understanding, the wakeup latency is known to the kernel (/sys/devices/system/cpu/cpuX/cpuidle/stateY/latency) and is taken into account when governor selects the next state ... is it possible to tweak the governor by setting the latency requirement (pm_qos_requirement(PM_QOS_CPU_DMA_LATENCY)) from userspace?

thanks, tim

Signature · 5 lines
[email protected]
http://tim.klingt.org

Lesser artists borrow, great artists steal.
  Igor Stravinsky
#3 lore raw
In reply to Tim Blechmann
Quoted 6 lines · Tim Blechmann

i am curious, do the values of CONFIG_HZ and CONFIG_NO_HZ somehow affect the scheduling latency (as reported by cyclictest) of a real-time/vanilla kernel, especially when CONFIG_HIGH_RES_TIMERS is enabled?

thnx, tim

Some anecdotal info...

From: http://lkml.indiana.edu/hypermail/linux/kernel/0906.2/03853.html

"I have disabled CONFIG_NOHZ long ago, since it really influences latency."

Quoted 1 line

From http://www.mail-archive.com/[email protected]/msg02300.html

"With CONFIG_NO_HZ=y or CONFIG_PPC_BESTCOMM_GEN_BD=y the latency
increases by approx. 100..150us, each."

The thread goes on for a while, but I don't think the CONFIG_NO_HZ question was resolved.

Looking at some old source (2.6.23.17-rt14), there was at least one longer IRQ disabled path if CONFIG_NO_HZ:

   void __noinstrument irq_enter(void)
   {
   #ifdef CONFIG_NO_HZ
        int cpu = smp_processor_id();
        if (idle_cpu(cpu) && !in_interrupt())
               tick_nohz_stop_idle(cpu);

   #endif
        ...
   #ifdef CONFIG_NO_HZ
        if (idle_cpu(smp_processor_id()))
               tick_nohz_update_jiffies();
   #endif
   }

But this code is different in later kernels. As of 2.6.29.4-rt19, it was:

   irq_enter()
      ...
      if (idle_cpu(cpu) && !in_interrupt()) {
         __irq_enter();
         tick_check_idle(cpu);
            // tick_check_idle() contains:

            #ifdef CONFIG_NO_HZ
               tick_nohz_stop_idle(cpu);
               tick_nohz_update_jiffies();
               tick_nohz_kick_tick(cpu);

- Frank Rowand
Sony Corporation of America