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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 02.05.17 at 10:32, <tim@xxxxxxx> wrote:
> At 04:52 -0600 on 28 Apr (1493355160), Jan Beulich wrote:
>> >>> On 27.04.17 at 11:51, <tim@xxxxxxx> 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@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel