Li, Aubrey <> wrote:
> 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()?
Please refer to previous reply mail, there's discussion about this issue in
that mail.
>
>>
>>>
>>> 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.
To really support above proposal, we still need some enhancements to
current CPU idle notification interface. Basically, add mechanism for
CPU idle framework to check CPU wakeups. For example,
typedef int (* cpu_idle_check_wakeup_t)(void *);
change
typedef void (* cpu_idle_enter_cbfn_t)(void *arg,
cpu_idle_callback_context_t ctx);
extern int cpu_idle_enter(int state, int flags);
to
typedef void (* cpu_idle_enter_cbfn_t)(void *arg,
cpu_idle_callback_context_t ctx, cpu_idle_check_wakeup_t check_wake,
void *wake_arg);
extern int cpu_idle_enter(int state, int flags,
cpu_idle_check_wakeup_t check_wake, void *wake_arg);
And a sample check wakeup implementation for mwait,
static int
mwait_check_wakeup(void *arg)
{
volatile uint32_t *mcpu_mwait = (volatile uint32_t *)arg;
return ((*mcpu_mwait & ~MWAIT_WAKEUP_IPI) == MWAIT_HALTED);
}
With above enhancement, CPU idle callbacks could use check_wakeup passed
in to detect wakeup events.
>
> Thanks,
> -Aubrey
Liu Jiang (Gerry)
OpenSolaris, OTC, SSG, Intel
