Re: give the TSC a fair chance [Was: [PATCHES] cpufreq_get(), cpufreq->get()]

[Dominik Brodowski <linux@dominikbrodowski.de>]

[-- Attachment #1.1: Type: text/plain, Size: 2208 bytes --]

On Wed, Apr 14, 2004 at 01:03:27PM -0700, john stultz wrote:
> On Wed, 2004-04-14 at 11:54, Dominik Brodowski wrote:
> > On Wed, Apr 14, 2004 at 11:24:21AM -0700, john stultz wrote:
> > > On Mon, 2004-04-12 at 05:04, Dominik Brodowski wrote:
> > > > However, this patch has one slight chance for a bug: if lost_count reaches
> > > > 50, a call to handle_cpufreq_delayed_work is scheduled, but does not execute
> > > > until lost_count reaches 50 again [e.g. when no lost ticks are
> > > > detected at the next call, but on the next 50 consecutive calls...]. As
> > > > keventd runs at -10 priority I doubt this will happen under normal
> > > > circumstances, though.
> > > 
> > > I'm not sure I follow this (lost_count == 50) bit. You're trying to
> > > schedule work only when we've noticed we're missing exactly 50 ticks?
> > 
> > No, not when we're missing exactly 50 ticks, but when we've detected 50
> > consecutive times we're missing ticks. That's half of the amount needed
> > before TSC is disabled and should mean enough time for cpufreq even under
> > heavy load to execute a cpufreq_get() call. 
> 
> Ok! Got it. Yea, in that case the patch looks fine.

Once 2.6.6 is out, I'll try to push it upstream (Dave -> Andrew -> Linus)

> As for the bug you
> mentioned, I'm not sure I understand how after you've scheduled 
> cpufreq_delayed_get_work() to run it wouldn't run? 

It would run, but too late. See below.

> So 50 consecutive interrupts occur where we notice we missed ticks, at
> this point we schedule the function. If the next tick we don't notice
> lost interrupts, why would the function not execute?

The following must happen:
50 consecutive interrupts with missed ticks occur
-> handle_cpufreq_get_delayed_work() is scheduled
0 to 50 more consecutive interrupts with missed ticks must occur,
then one or more interrupts with zero or one missed ticks so that lost_count
is reset to zero, and then
50 consecutive interrupts with missed ticks again.
_AND_ since the scheduling of handle_cpufreq_get_delayed_work() above
this handler running at -10 priority must not have been called ==> so 
it's really a very unlikely situation.

	Dominik

[-- Attachment #1.2: Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 143 bytes --]

_______________________________________________
Cpufreq mailing list
Cpufreq@www.linux.org.uk
http://www.linux.org.uk/mailman/listinfo/cpufreq