[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Xen-devel] [PATCH] x86 fixes for 3.3 impacting distros (v1).
- To: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
- From: "H. Peter Anvin" <hpa@xxxxxxxxx>
- Date: Thu, 28 Jun 2012 07:42:12 -0700
- Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, "Siddha, Suresh B" <suresh.b.siddha@xxxxxxxxx>, x86@xxxxxxxxxx, Jason Garrett-Glaser <jason@xxxxxxxx>, marmarek@xxxxxxxxxxxxxxxxxxxxxx, rostedt@xxxxxxxxxxx, linux-kernel@xxxxxxxxxxxxxxx, mingo@xxxxxxxxxx, tglx@xxxxxxxxxxxxx, cyclonusj@xxxxxxxxx
- Delivery-date: Thu, 28 Jun 2012 14:43:12 +0000
- List-id: Xen developer discussion <xen-devel.lists.xen.org>
On 06/28/2012 07:28 AM, Konrad Rzeszutek Wilk wrote:
> Peter mentioned to me had some ideas about software PAT table lookup. I am not
> exactly sure what he meant by that.
I could see the kernel have programmable PAT values rather than fixed if
and only if it can be showed to have no measurable performance impact.
> Just to summarize, there were two ways proposed to fix this:
> 1). Make __page_change_attr_set_clr use a new wrapper: pte_attr, that calls
> pte_val (pvops call) instead of pte_flag (native). Here is the patch:
> (no perf regressions across all platforms)
> 2). Introduce a new pvops call - pte_flags, which would make pte_flags
> (which currently is doing just a bit mask) be pvops-fied.
> (weird results on AMD, other platforms had no perf degradations)
> 3). (not posted), was to do 2), but alter the alternative_asm and instead
> use asm_goto to
> make the compiler use less registers and hopefully reduce the code:
> But the results I got showed worst performance on baremetal.. which was
> Perhaps it is compiler related - never got to follow up on it.
OK, let me be blunt: I will unconditionally veto any of these.
> I also chatted with the core Xen hypervisor folks about adding in the context
> switch code
> to alter the PAT layout - but they were not keen a about it - and I am not
> sure how much
> CPU cycles one loses by doing a wrmsr to the PAT register on every guest
> context switch
> (worst case when on has a pvops kernel and a old-style one - where the WC bit
> would differ)?
And you're comparing that to a bunch of new pvops calls? The discussion
shouldn't even have started until you had ruled out this solution and
had data to show it.
Xen-devel mailing list