Re: [RFC] cpufreq: governor: Set MIN_LATENCY_MULTIPLIER to 20

[Thomas Renninger]

On Tuesday, February 26, 2013 04:20:07 PM Viresh Kumar wrote:
> On 26 February 2013 16:14, Thomas Renninger <trenn@xxxxxxx> wrote:
> > Redefining MIN_LATENCY_MULTIPLIER shouldn't hurt that much, but this looks
> > like a workaround.
> > It only modifies the minimal sampling rate that userspace can set.
> 
> Yes.
> 
> > You would still need to set something from userspace to get the perfect
> > sampling rate for this platform.
> 
> Yes. We still need to fix sampling rate from userspace.
> 
> > I wonder where the cpufreq driver does get the 1ms latency from?
> > Is this value valid?
> > The driver should return the correct latency, then there is no need for
> > workarounds like this.
> 
> I am talking about ARM Vexpress TC2 (Test Chip) big LITTLE SoC here. Its
> not a production type SoC and freq change is a bit slow here. Its really
> around 1 ms :)
> 
> But the real systems may not have this big of latency.
> 
> Anyway, how do you come to 100 value in your initial patch. What motivated
> you to fix it there?
Iirc there were two things:
   - max latency does not make any sense at all and it got reverted
   - min latency makes some sense -> prevent a system to get unresponsive
     due to too small sampling rate forced by userspace.
     I reduced the min_sampling rate calculation to better be able to test
     best sampling rate values by trying them out.

But I agree, that it should not harm to lower the MIN_LATENCY_MULTIPLIER.
In fact it doesn't change anything as long as userspace does not override
the sample factor and the system should still not stall (this is what the 
min_sampling_rate tries to prevent).

So from what you describe above:
This patch makes sense, especially to test and debug some early HW where
latency values might be big (or bogus). Then the developer can still enforce
lower polling rates, but they can still not be that low that userspace is able 
to stall the system.

No objections from my side if this patch helps you to get further.

   Thomas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/