[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH v2 0/3] mwait support for AMD processors

On Mar 28, 2019, at 11:04, Woods, Brian <Brian.Woods@xxxxxxx> wrote:

This patch series add support and enablement for mwait on AMD Naples
and Rome processors.  Newer AMD processors support mwait, but only for
c1, and for c2 halt is used.  The mwait-idle driver is modified to be
able to use both mwait and halt for idling.

Would you mind if I create a Xen Project JIRA ticket, or a wiki page, to track requirements and implementations related to this patch series?

From the initial thread [1]:
On certain AMD families that support mwait, only c1 can be reached by
+ * mwait and to reach c2, halt has to be used.
+ */
+#define CPUIDLE_FLAG_USE_HALT        0x2

Could you point us at where in the manuals this behavior is described?
While PM Vol 2 has a chapter talking about P-states, I can't seem to
find any mention of C-states there.

IIRC it's in the NDA PPR and internally it's in some other documents. 
We don't have support to use mwait while in CC6 due to caches being 
turned off etc.  If we did have mwait suport for CC6, we'd use that here 
(basically mirroring Intel).  Sadly I don't think we have any public 
information directly detailing this information.  

Can this be documented in the patch comment, or an AMD-specific page on wiki.xenproject.org?  It's a requirement/input to all possible implementations.  

From a comment in the April 2018 Linux patch by Yazen [2]:
> x86/smpboot: Don't use mwait_play_dead() on AMD systems
> Recent AMD systems support using MWAIT for C1 state. However, MWAIT will
> not allow deeper cstates than C1 on current systems.
> play_dead() expects to use the deepest state available.  The deepest state
> available on AMD systems is reached through SystemIO or HALT. If MWAIT is
> available, it is preferred over the other methods, so the CPU never reaches
> the deepest possible state.
> Don't try to use MWAIT to play_dead() on AMD systems. Instead, use CPUIDLE
> to enter the deepest state advertised by firmware. If CPUIDLE is not
> available then fallback to HALT.

For the ticket/wiki: what are the expected benefits of the proposed Xen change?  Would it reduce idle power consumption on Ryzen 1000/2000/3000? Epyc 3000/7000? Any sample data available for idle power before/after the v2 patch?

From a thread [3] posted by Jan this week, "x86/AMD: make C-state handling independent of Dom0":
> The 3rd patch is my counterproposal to Brian's intended abuse (as I would call it) of the mwait-idle driver. 

Do we need a new, patch-independent, thread for convergence of candidate implementations which address the requirements (documented in ticket/wiki)?  Should discussion move from the initial thread [1] to the counter-proposal thread [3]?  Or this thread?


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.