[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] x86 patch ping
>>> Andrew Cooper <andrew.cooper3@xxxxxxxxxx> 04/15/16 7:12 PM >>> >On 08/04/16 13:10, Jan Beulich wrote: >> http://lists.xen.org/archives/html/xen-devel/2016-03/msg02167.html >> (with the 1st patch having gone in already) > >Apologies for the delay on this. I now have results in. > >The 64bit performance hit is within the noise (as expected) but sadly, Thanks - at least something good here. >the performance impact of v3 on 32bit guests is even worse than previous >rounds. > >From lmbench: > >mmap() has an 85% latency hit. >pagefaults (on /local/scratch) gets a 78% hit. >pipe latency gets a 58% hit. >process fork()/exit() gets a 47% hit. > >In each of these cases, that is about 20% worse that previous measurements. I have to admit that I have a _very_ hard time seeing why the most recent adjustments would have made things worse. >As it currently stands, we really can't justify taking the fix in its >current form. Which raises the question of alternatives. Fact is that we're having a problem to solve, and no solution getting things back to architecturally correct behavior other than this one. Which makes me wonder whether we shouldn't take the change irrespective of its performance effect, provided that performance goes back up if people use "no-smep" and/or "no-smap" as appropriate. (Specifying to use these options to restore architecturally correct behavior is, imo, not an acceptable thing to do, but suggesting their use to get performance back for those who value security less than performance imo is an option.) Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |