From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
Andrew Cooper <andrew.cooper3@citrix.com>,
xen-devel <xen-devel@lists.xen.org>
Subject: Re: Converting heap page_infos to contiguous virtual
Date: Fri, 15 Jul 2016 12:04:26 -0400 [thread overview]
Message-ID: <20160715160426.GH18090@char.us.oracle.com> (raw)
In-Reply-To: <56aecbd7-c242-62a7-deaa-70d6836a3f46@oracle.com>
[-- Attachment #1: Type: text/plain, Size: 1175 bytes --]
On Fri, Jul 15, 2016 at 10:53:51AM -0400, Boris Ostrovsky wrote:
> On 07/14/2016 09:29 AM, Andrew Cooper wrote:
> >
> > However, I would recommend getting something functioning first, before
> > trying to optimise it.
>
> There are two fairly independent parts to improving scrubbing: one is
> making it asynchronous and second is improving clear_page() performance.
> Whole-RAM mapping is needed for the latter.
Attaching a nice graph of different memset on Broadwell (credits go to
Joao for doing the testing). Skylake is 10% faster than Broadwell.
>
> >
> > There is probably a lot to be gained simply by improving clear_page().
>
> The biggest improvement comes from switching to AVX(2) when available.
> It's been a while since I ran those tests so I will have to re-measure
> it but my recollection is that 4K was too small to see significant changes.
>
> A potential improvement might come from dropping (or, rather, deferring)
> sfence in clear_page_sse2. I don't know how much this would buy us though.
>
> -boris
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> https://lists.xen.org/xen-devel
[-- Attachment #2: broadwell_memset.png --]
[-- Type: image/png, Size: 25670 bytes --]
[-- Attachment #3: Type: text/plain, Size: 127 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
next prev parent reply other threads:[~2016-07-15 16:04 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-13 19:44 Converting heap page_infos to contiguous virtual Boris Ostrovsky
2016-07-13 20:02 ` Andrew Cooper
2016-07-13 20:17 ` Boris Ostrovsky
2016-07-13 20:28 ` Boris Ostrovsky
2016-07-13 20:34 ` Andrew Cooper
2016-07-13 20:57 ` Boris Ostrovsky
2016-07-13 21:06 ` Andrew Cooper
2016-07-13 21:43 ` Boris Ostrovsky
2016-07-14 13:29 ` Andrew Cooper
2016-07-15 14:53 ` Boris Ostrovsky
2016-07-15 15:19 ` Andrew Cooper
2016-07-15 15:35 ` Boris Ostrovsky
2016-07-15 16:04 ` Konrad Rzeszutek Wilk [this message]
2016-07-15 16:07 ` Andrew Cooper
2016-07-14 10:25 ` George Dunlap
2016-07-14 10:34 ` Andrew Cooper
2016-07-14 12:42 ` Julien Grall
2016-07-14 13:10 ` Andrew Cooper
2016-07-15 14:39 ` Boris Ostrovsky
2016-08-01 12:09 ` 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=20160715160426.GH18090@char.us.oracle.com \
--to=konrad.wilk@oracle.com \
--cc=George.Dunlap@eu.citrix.com \
--cc=andrew.cooper3@citrix.com \
--cc=boris.ostrovsky@oracle.com \
--cc=xen-devel@lists.xen.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.