scheduling latency & CONFIG_HZ

scheduling latency & CONFIG_HZ

[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

-- 
tim@klingt.org
http://tim.klingt.org

The price an artist pays for doing what he wants is that he has to do
it.
   William S. Burroughs

Re: scheduling latency & CONFIG_HZ

[Thomas Gleixner]

On Wed, 11 Nov 2009, Tim Blechmann wrote:

> 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

Re: scheduling latency & CONFIG_HZ

[Tim Blechmann]

[-- Attachment #1: Type: text/plain, Size: 1112 bytes --]

>> 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

-- 
tim@klingt.org
http://tim.klingt.org

Lesser artists borrow, great artists steal.
  Igor Stravinsky


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: scheduling latency & CONFIG_HZ

[Frank Rowand]

On 11/11/09 10:44, Tim Blechmann wrote:
> 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."


>From http://www.mail-archive.com/linux-rt-users@vger.kernel.org/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