Re: [PATCH 0/5] x86: improve PDX <-> PFN and alike translations

From: "Jan Beulich" <jbeulich@suse.com>
To: andrew.cooper3@citrix.com
Cc: xen-devel@lists.xenproject.org
Subject: Re: [PATCH 0/5] x86: improve PDX <-> PFN and alike translations
Date: Thu, 01 Mar 2018 00:22:32 -0700	[thread overview]
Message-ID: <5A97AA380200007800128BE8@prv-mh.provo.novell.com> (raw)
In-Reply-To: <94e4562c-90fe-0cd4-ea5f-4c5c568a5023@citrix.com>

>>> Andrew Cooper <andrew.cooper3@citrix.com> 02/28/18 6:26 PM >>>
>On 28/02/18 13:51, Jan Beulich wrote:
>> 1: remove page.h and processor.h inclusion from asm_defns.h
>> 2: use PDEP for PTE flags insertion when available
>> 3: use PDEP/PEXT for maddr/direct-map-offset conversion when available
>> 4: use PDEP/PEXT for PFN/PDX conversion when available
>> 5: use MOV for PFN/PDX conversion when possible
>>
>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>
>Ah - so this was the series you were on about which would have an
>interesting time in combination with my nop autosizing.
>
>Do you have performance numbers for these changes?  I can certainly see
>the attraction of using BMI2 when available, but do the associated costs
>>on incompatible hardware worth it?  I'm thinking specifically of turning
>all this inline bit manipulation into function calls?  (I genuinely
>don't know the answer, and it might be entirely fine, but I'm concerned
>about whether it may not be).

To be honest, performance on older hardware is of secondary concern to
me here, BMI2 isn't all that new anymore. The primary concern is
performance on recent hardware (which certainly is being improved) and
the much improved readability of generated code (which is particularly
relevant when one needs to investigate issues in one of the bigger
functions involving such translations.

>What generation of binutils do you expect this all to work with?

The respective change (d02603dc20) was done in August 2015.

>As for the pte flags, there is a much more simple approach which I've
>considered investigating in the past, and I think warrants discussing here.
>
>By switching 'unsigned int flags' to 'unsigned long flags', we avoid any
>need for packing in the first place.  Being 64bit only these days, all
>other PTE calculations are already 64bit operations, and the masks are
>probably already available in GPRs at the use-sites.  I.e. I think the
>use of 64bit flags will make better code than even this proposal.

If that doesn't result in overly many extra REX prefixes and/or full 64-bit
constant loads, perhaps. But that would affect just one of the five patches
here anyway.

Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel