Re: [PATCH 1/3] clockevents: Use an atomic RCU notifier forclockevents

[Thomas Gleixner]

On Tue, 6 Sep 2011, Andi Kleen wrote:

> On Tue, Sep 06, 2011 at 09:23:55PM +0200, Thomas Gleixner wrote:
> > On Mon, 29 Aug 2011, Andi Kleen wrote:
> > 
> > > From: Andi Kleen <ak@xxxxxxxxxxxxxxx>
> > > 
> > > Use an atomic_notifier instead of a raw_notifier for the clockevents
> > > notification.
> > > 
> > > This avoids a global lock in the idle path, is a scalability
> > > problem. With this patch we don't have a global lock anymore
> > > at least on systems with an always running timer.
> > 
> > And why is that code called on a system with an always running local
> > apic timer at all? The broadcast horror is explicitely only for those
> > systems with wreckaged hardware.
> 
> Because the notifier is before the check for always running local apic timer.

The idle code, at least the one in drivers/idle/intel_idle.c, does
_NOT_ call into that code at all when a reliable lapic timer is
available:

        if (!(lapic_timer_reliable_states & (1 << (cstate))))
	   clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, &cpu);

....

	if (boot_cpu_has(X86_FEATURE_ARAT))     /* Always Reliable APIC Timer */
                lapic_timer_reliable_states = LAPIC_TIMER_ALWAYS_RELIABLE;

Same applies for drivers/acpi/processor_idle.c

Though according to your changelog something is calling that
clockevents callchain despite of an ALWAYS RUNNING local apic
timer. That means:

Either you are using different code or your machine does not have that
ARAT flag set.

 - If your machine has the ARAT feature, then calling into the
   clockevents code is fcking wrong.

 - If your machine does NOT have the ARAT feature, then removing that
   lock is nice, but has ABSOLUTELY NOTHING TO DO WITH AN ALWAYS
   RUNNING TIMER.

> You also get bonus points for a incredible convoluted call chain,
> about 50% of it being unnecessary and full of scalability problems.

I gladly accept those bonus points for writing correct code, which was
never meant to be scalable on larger systems at all. Assuming that
HPET broadcasting is scalable in any way is just hilarious.

I'm sorry that I'm not able to return the favour of bonus points for
you. There are no bonus points for sloppy patches, sloppy changelogs
and ignorance vs. the problems at hand.

I'm reserving those bonus points for you once you come up with the
patches which remove those 50 percent unnecessary code along with the
scalability problems without breaking the world and some
more. According to your profound analysis above and the other perfect
patches (including the perfect changelogs) which I had the pleasure to
review today, this should be a trivial to solve problem for you.

Thanks,

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