Liu, Jiang wrote: > Li, Aubrey <> wrote: > >> < Forward to mailing list to request more comments > >> >> Bill.Holler wrote: >> >> >>> Hi Aubrey, >>> >>> This is in sync with what we where thinking here. Please see inline. >>> >>> >>> Li, Aubrey wrote: >>> >>>> I'm doing investigation about re-initialize APIC timer after wake up >>>> from deep c-state. And obviously I haven't finished, I need your >>>> suggestions and comments, :-) >>>> >>>> APIC timer is used by the cyclic subsystem, provides per-CPU >>>> interval timers and interrupts. My initial thoughts as follows, >>>> please correct me. >>>> >>>> 1) before enter deep c-state, we read current count register of APIC >>>> timer, since apic timer will generate interrupt after count-down to >>>> ZERO, we know when exactly the interrupt will happen on this CPU. >>>> >>>> >>> The top cyclic_t structure on this cpu's cyclic heap has the >>> hrtime_t when it should expire. We can either read the cpu's >>> APIC timer register directly and compute the expiration time, >>> or we can use the hrtime_t from the top cyclic on this cpu's >>> cyclic heap. >>> >>> Is the local APIC fast to read? Is it faster than a memory read? >>> Using the hrtime_t in the top cyclic_t will take a few memory >>> reads which may not be in the cpu's cache. >>> >>> >> I considered this issue. Since there must be a time gap between cbe >> reprogram >> and the exact point before enter deep c-state, using the count in APIC >> timer should >> be more accurate.
cbe_reprogram() looks like a good place to start for reprogramming the local APIC's timer during idle fixup from deep c-state. The cyclic and cbe interfaces use hrtime_t nanoseconds since boot. The local APIC's interval timer is programmed by the psm (processor set module). The psm converts cbe's hrtime_t nanoseconds since boot into nanosecond interval values. Bill
