Subject: schedule_timeout sleeps too long after dividing CPU frequency

From: [email-masked] (Viresh Kumar)
Date: Fri, 15 May 2015 09:46:32 +0530

On 14-05-15, 16:48, Mason wrote:
> I don't know. Is it not obvious (to someone who knows what to
> look for) from reading the smp_twd.c source?
> 
> How do I run the TWD in one-shot mode?

I haven't refreshed my memory for the earlier reply, but I have tried
to go through the code again.

The logic is this:
- Oneshot mode is only useful if we are going to support NO_HZ mode.
  i.e. we can disable the clkevt device during CPU idle ..
- For that to work, or in other words for the CPU to wake up from the
  idle state, we need a broadcast timer. Which will wake up the idle
  cpu and its clkevt device.

  You don't have this 'broadcast' timer in your case and so we aren't
  able to switch to oneshot mode.

  Even if you do that, you will be stuck in LOW resolution mode. And
  so you probably leave this timer as is and use a out-of-CPU-domain
  timer for this work, which can support high resolution mode.

> http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0407g/CIHGECHJ.html

What core does your platform has? Cortex A9? Doesn't that uses this
timer instead: drivers/clocksource/arm_arch_timer.c ?

> "The global timer is clocked by PERIPHCLK."
> 
> PERIPHCLK = CPUCLK/2
> 
> Change the CPUCLK, change the PERIPHCLK.

I am not sure if GPT on SPEAr was an ARM provided timer. But it
definitely doesn't depend on cpu-clk and so no cpufreq support in
that.

> > The same timer is probably used for SPEAr (the platform
> > I used to work on):
> > 
> > http://lxr.free-electrons.com/source/arch/arm/mach-spear/time.c?v=3.14
> 
> Did that platform use cpufreq DFS?

Yes, but the clock to that timer was independent of CPU's clock.

-- 
viresh