Messages in this thread | | | Date | Sat, 19 Dec 2009 01:44:31 +0300 | From | Cyrill Gorcunov <> | Subject | Re: [PATCH 2/2] x86/apic: check global clockevent in lapic timer setup |
| |
On Fri, Dec 18, 2009 at 10:13:52AM -0800, Pan, Jacob jun wrote: ... > > > >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. > [[JPAN]] that seems to be much more efficient and we can have platform specific > way of calibration too with the x86_init abstraction.
Good idea I think!
> > > >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. > > > [[JPAN]] x86 does have MSR_FSB_FREQ to read bus frequency then the DCR to figure > out LAPIC timer freq. but i guess not all CPU models have that. so having > the abstraction would be a plus for those do have reliable reporting of lapic > freq.
IIRC old apics may use independent clock signal too, though I dont think that we ever switch (espec novadays) to use it due to obsolescense of such chips :)
> > >> 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. > > > [[JPAN]] thanks for the explanation. so if we have per cpu timer that is > always-on, and don't have a broadcast timer, then the dummy device would not > be needed, correct? > >
Hmm... We may be using nmi detector, so I think we still need dummy clockevent device to send broadcast "time" IPI, or per-cpu timer interrupt handler have to call the local apic interrupt routine. At least that is how I imagine this scheme :)
> >Thanks, > > > > tglx > -- Cyrill
| |