Message-ID: <alpine.LFD.2.00.0912181704360.2755@localhost.localdomain>
Date:	Fri, 18 Dec 2009 17:35:41 +0100 (CET)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	"Pan, Jacob jun" <jacob.jun.pan@...el.com>
cc:	"H. Peter Anvin" <hpa@...ux.intel.com>,
	Cyrill Gorcunov <gorcunov@...il.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"x86@...nel.org" <x86@...nel.org>
Subject: RE: [PATCH 2/2] x86/apic: check global clockevent in lapic timer
 setup

On Thu, 17 Dec 2009, Pan, Jacob jun wrote:
> >-----Original Message-----
> >From: H. Peter Anvin [mailto:hpa@...ux.intel.com]
> >Sent: Thursday, December 17, 2009 2:34 PM
> >To: Pan, Jacob jun
> >Cc: Cyrill Gorcunov; linux-kernel@...r.kernel.org; x86@...nel.org
> >Subject: Re: [PATCH 2/2] x86/apic: check global clockevent in lapic timer setup
> >
> >On 12/17/2009 02:31 PM, Pan, Jacob jun wrote:
> >>> Wouldn't be better to operate the same way as in case of "noapictimer"
> >>> boot option. I guess the non-pc x86 midplatforms you're mentioning
> >>> do not use SMP ever but just to be consistent in code.
> >>>
> >> [[JPAN]] We do use SMP with hyper threading in Moorestown.
> >> In that case we have a per cpu platform timer without global clockevent.
> >> so i think we don't want the dummy lapic event. we don't want to use the
> >> broadcast mechanism as mentioned in the comments before disabling lapic
> >> timer.
> >>
> >> For moorestown, I can use x86_init.timers.setup_percpu_clockev
> >> abstraction function so that Moorestown platform does not need to call
> >> setup_boot_APIC_clock() if per cpu platform timer is used. so many IFs :).
> >>
> >> But in the case of having constant and always on LAPIC timer, we still do
> >> not want the dummy lapic clockevent and the broadcast. we will just have
> >> per cpu always on local apic timers without global clockevent device.
> >
> >OK, I'm not entirely sure I follow this, and I'm not sure someone trying
> >to understand the code in five years would, either.  I don't really see
> >the above translating into "we don't have a global clockevent, therefore
> >we shouldn't initialize (but should still not disable) the local APIC
> >timer."
> >
> >	-hpa
> [[JPAN]] There is some thing wrong in my logic.
> 
> If we have always running lapic timer, and per cpu platform timers, we would
> still want to set up the lapic timer without global clockevent, just without
> calibration. perhaps use a platform specific setup_percpu_clockev() function.
> 
> So i don't think we need this patch at the moment, maybe we only need to do a
> sanity check for global clockevent in calibrate_APIC_clock().

No, we need to fix the whole lapic timer calibration logic first.

There is no reason why we don't calibrate the lapic at the same time
as we calibrate the TSC.

Another question is why there is no way to read out the lapic clock
frequency from some config registers or wherever the chip designers
decided to hide that. There is no real reason why the lapic timer
calibration needs to be extremly precise.

> Honestly, i don't fully understand how the dummy lapic event device
> is related to the broadcast mechanism. can someone explain why we
> register the dummy lapic clockevent?

The broadcast mechanism is there in the first place to work around the
APIC stops in deeper C-states idiocy. 

Then we need to support the disable lapic timer command line option
(even on SMP) so we make use of the existing broadcast mechanism and
register the dummy device to have a per cpu clock event device.

Thanks,

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

Powered by blists - more mailing lists