> From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: Thursday, December 13, 2018 4:37 PM > > >>> On 13.12.18 at 02:28, <kevin.t...@intel.com> wrote: > > btw I checked your original mail: > > > > (XEN) [<ffff82d0802e2403>] mwait-idle.c#mwait_idle+0x2a5/0x381 > > xen/arch/x86/cpu/mwait-idle.c:802 > > > > 788 if (cpu_is_haltable(cpu)) > > 789 mwait_idle_with_hints(eax, > MWAIT_ECX_INTERRUPT_BREAK); > > 790 > > 791 after = cpuidle_get_tick(); > > 792 > > 793 cstate_restore_tsc(); > > 794 trace_exit_reason(irq_traced); > > 795 TRACE_6D(TRC_PM_IDLE_EXIT, cx->type, after, > > 796 irq_traced[0], irq_traced[1], irq_traced[2], > irq_traced[3]); > > 797 > > 798 /* Now back in C0. */ > > 799 update_idle_stats(power, cx, before, after); > > 800 local_irq_enable(); > > 801 > > -> 802 if (!(lapic_timer_reliable_states & (1 << cstate))) > > 803 lapic_timer_on(); > > 804 > > 805 sched_tick_resume(); > > 806 cpufreq_dbs_timer_resume(); > > > > Looks above code is different from staging: > > > > acpi_processor_idle: > > acpi_idle_do_entry: > > acpi_processor_ffh_cstate_enter: > > mwait_idle_with_hints > > > > there is no mwait_idle alone. and even with compiler optimization I didn't > > find code sequence like above... > > You're looking at two entirely different code paths, only one of > which can be in use in any particular case: Either the idle > entering routine used is acpi_processor_idle(), or (when the > processor is supported by that driver code) it is mwait_idle(). > See mwait_idle_init() for when the latter gets used; the former > may get installed at the point the Dom0 kernel reports ACPI > C-state data (and only when mwait_idle() is not in use). >
yes, I missed the other path. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel