From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Jan Beulich <JBeulich@suse.com>,
xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [PATCH 0/5] x86: improve PDX <-> PFN and alike translations
Date: Wed, 28 Feb 2018 16:47:03 +0000 [thread overview]
Message-ID: <94e4562c-90fe-0cd4-ea5f-4c5c568a5023@citrix.com> (raw)
In-Reply-To: <5A96C1D602000078001ACCEC@prv-mh.provo.novell.com>
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).
What generation of binutils do you expect this all to work with?
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.
~Andrew
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
next prev parent reply other threads:[~2018-02-28 17:26 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-28 13:51 [PATCH 0/5] x86: improve PDX <-> PFN and alike translations Jan Beulich
2018-02-28 13:56 ` [PATCH 1/5] x86: remove page.h and processor.h inclusion from asm_defns.h Jan Beulich
2018-02-28 13:57 ` [PATCH 2/5] x86: use PDEP for PTE flags insertion when available Jan Beulich
2018-02-28 13:57 ` [PATCH 3/5] x86: use PDEP/PEXT for maddr/direct-map-offset conversion " Jan Beulich
2018-02-28 13:58 ` [PATCH 4/5] x86: use PDEP/PEXT for PFN/PDX " Jan Beulich
2018-02-28 14:35 ` Jan Beulich
2018-02-28 13:59 ` [PATCH 5/5] x86: use MOV for PFN/PDX conversion when possible Jan Beulich
2018-02-28 16:47 ` Andrew Cooper [this message]
2018-03-01 7:22 ` [PATCH 0/5] x86: improve PDX <-> PFN and alike translations Jan Beulich
2018-03-05 8:37 ` Jan Beulich
2018-03-06 8:45 ` Jan Beulich
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=94e4562c-90fe-0cd4-ea5f-4c5c568a5023@citrix.com \
--to=andrew.cooper3@citrix.com \
--cc=JBeulich@suse.com \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).