Re: [PATCH v2] x86/mm: also flush TLB when putting writable foreign page reference

From: "Jan Beulich" <JBeulich@suse.com>
To: Tim Deegan <tim@xen.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Julien Grall <julien.grall@arm.com>,
	xen-devel <xen-devel@lists.xenproject.org>,
	Jann Horn <jannh@google.com>
Subject: Re: [PATCH v2] x86/mm: also flush TLB when putting writable foreign page reference
Date: Tue, 02 May 2017 02:50:03 -0600	[thread overview]
Message-ID: <5908645B0200007800155A54@prv-mh.provo.novell.com> (raw)
In-Reply-To: <20170502083215.GA90479@deinos.phlegethon.org>

>>> On 02.05.17 at 10:32, <tim@xen.org> wrote:
> At 04:52 -0600 on 28 Apr (1493355160), Jan Beulich wrote:
>> >>> On 27.04.17 at 11:51, <tim@xen.org> wrote:
>> > At 03:23 -0600 on 27 Apr (1493263380), Jan Beulich wrote:
>> >> ... it wouldn't better be the other way around: We use the patch
>> >> in its current (or even v1) form, and try to do something about
>> >> performance only if we really find a case where it matters. To be
>> >> honest, I'm not even sure how I could meaningfully measure the
>> >> impact here: Simply counting how many extra flushes there would
>> >> end up being wouldn't seem all that useful, and whether there
>> >> would be any measurable difference in the overall execution time
>> >> of e.g. domain creation I would highly doubt (but if it's that what
>> >> you're after, I could certainly collect a few numbers).
>> > 
>> > I think that would be a good idea, just as a sanity-check.
>> 
>> As it turns out there is a measurable effect: xc_dom_boot_image()
>> for a 4Gb PV guest takes about 70% longer now. Otoh it is itself
>> responsible for less than 10% of the overall time libxl__build_dom()
>> takes, and that in turn is only a pretty small portion of the overall
>> "xl create".
> 
> Do you think that slowdown is OK?  I'm not sure -- I'd be inclined to
> avoid it, but could be persuaded, and it's not me doing the work. :)

Well, if there was a way to avoid it in a clean way without too much
code churn, I'd be all for avoiding it. The avenues we've explored so
far either didn't work (using pg_owner's dirty mask) or didn't promise
to actually reduce the flush overhead in a meaningful way (adding a
separate mask to be merged into the mask used for the flush in
__get_page_type()), unless - as has been the case before - I didn't
fully understand your thoughts there.

Jan

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