On Friday, December 16, 2016 09:13:13 PM Xiao Guangrong wrote: > > I mean the it is unlinked from the upper level page structure. > Ah, ok. But even in that case, the retries won’t happen unless somebody was actively trying to write to the just unlinked page table at the same time, which can cause bigger problems. In any case, I can move the pgtable walk inside the loop, as there doesn’t seem to be any downside in it. > > > >> I am curious that did you see this retry is really helpful? :) > > > > No, I haven’t done a comparison with and without the retries since it seemed to be a fairly simple optimization. And it may not be straightforward to reliably reproduce the situation where it will help. > > So we are not sure if retry is really useful... > > After this change, all !W page fault can go to this fast path, i think it does not hurt the > performance, but we'd better have a performance test. Yes, more faults can go into this fast path now. However, all except those where we actually need to fix the acc-tracking or write-prot will break out in the first iteration, so the retries won’t happen for those. For the cases where we actually do retry, the alternative could be another VMEXIT, which would obviously be a lot more expensive. But I’ll try to think of some way to test the performance. Thanks, Junaid -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
