[lkml]   [2009]   [Dec]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [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

     \ /
      Last update: 2009-12-18 23:47    [W:0.024 / U:39.012 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site