On Tue, 2019-10-01 at 15:16 -0400, Nitesh Narayan Lal wrote: > On 10/1/19 12:21 PM, Alexander Duyck wrote: > > On Tue, 2019-10-01 at 17:35 +0200, David Hildenbrand wrote: > > > On 01.10.19 17:29, Alexander Duyck wrote: <snip> > > > > > > > > As far as possible regressions I have focused on cases where performing > > > > the hinting would be non-optimal, such as cases where the code isn't > > > > needed as memory is not over-committed, or the functionality is not in > > > > use. I have been using the will-it-scale/page_fault1 test running with 16 > > > > vcpus and have modified it to use Transparent Huge Pages. With this I see > > > > almost no difference with the patches applied and the feature disabled. > > > > Likewise I see almost no difference with the feature enabled, but the > > > > madvise disabled in the hypervisor due to a device being assigned. With > > > > the feature fully enabled in both guest and hypervisor I see a regression > > > > between -1.86% and -8.84% versus the baseline. I found that most of the > > > > overhead was due to the page faulting/zeroing that comes as a result of > > > > the pages having been evicted from the guest. > > > I think Michal asked for a performance comparison against Nitesh's > > > approach, to evaluate if keeping the reported state + tracking inside > > > the buddy is really worth it. Do you have any such numbers already? (or > > > did my tired eyes miss them in this cover letter? :/) > > > > > I thought what Michal was asking for was what was the benefit of using the > > boundary pointer. I added a bit up above and to the description for patch > > 3 as on a 32G VM it adds up to about a 18% difference without factoring in > > the page faulting and zeroing logic that occurs when we actually do the > > madvise. > > > > Do we have a working patch set for Nitesh's code? The last time I tried > > running his patch set I ran into issues with kernel panics. If we have a > > known working/stable patch set I can give it a try. > > Did you try the v12 patch-set [1]? > I remember that you reported the CPU stall issue, which I fixed in the v12. > > [1] https://lkml.org/lkml/2019/8/12/593 > > > - Alex > > I haven't tested it. I will pull the patches and give it a try. It works with the same QEMU changes that mine does right? If so we should be able to get an apples-to-apples comparison. Also, instead of providing lkml.org links to your patches in the future it might be better to provide a link to the lore.kernel.org version of the thread. So for example the v12 set would be: https://lore.kernel.org/lkml/20190812131235.27244-1-nitesh@xxxxxxxxxx/ The advantage is you can just look up the message ID in your own inbox to figure out the link, and it provides raw access to the email if needed. Thanks. - Alex
