Liu Jiang wrote: >> The Deep C-state exit side was optimized for speed because the CPU >> likely has real work to do. C-state exit is lock-less and only does >> a few memory writes and 1 write to the LAPIC Timer. LAPIC write >> performance was measured while doing the C-state work. I do not >> remember the exact write time. IIRC LAPIC access is faster than an >> un-cached memory write.
> Seems good news to us which means that there won't big difference > even on the exiting side, right? What about when the dtrace probe is enabled in do_interrupt()? > >> >> We put back support for Intel's Always Running APIC Timer on Friday. >> Solaris does not re-initialize the LAPIC Timer on future Intel >> Processors when exiting Deep C-states. :-) > I have an idea here to optimize the deep C path in idle > thread. As we know, > there are some existing CPUs on which LAPIC timer will be stopped > after entering C state deeper than C2. And on other future CPUs, > they will most > likely support ARAT. With ARAT, idle thread doesn't need to deal with > timer at all. So the idea here is to use CPU idle notification to > optimize timer > relative operation in idle path. On platform without ARAT, we register > timer manipulating functions > (hpet_use_lapic_timer/hpet_use_hpet_timer) as idle callback, then > they will be called when entering > into/exiting from > idle state. On platform with ARAT, we don't register those function as > idle callback, so no timer relative operation will be incured > in idle thread. > By that way, we could optimize for future systems with ARAT > and won't sacrifice current systems without ARAT. And code to > implement deep C idle will be simplified and easier to understand. > Any comment about the idea? > This is doable. Please be aware lapic timer need to re restored when the cpu is not in halt cpu set and if there is something runnable locally. Thanks, -Aubrey
