Laurent Dufour <lduf...@linux.vnet.ibm.com> writes: > On 30/04/2018 20:43, Punit Agrawal wrote: >> Hi Laurent, >> >> I am looking to add support for speculative page fault handling to >> arm64 (effectively porting this patch) and had a few questions. >> Apologies if I've missed an obvious explanation for my queries. I'm >> jumping in bit late to the discussion. > > Hi Punit, > > Thanks for giving this series a review. > I don't have arm64 hardware to play with, but I'll be happy to add arm64 > patches to my series and to try to maintain them.
I'll be happy to try them on arm64 platforms I have access to and provide feedback. > >> >> On Tue, Apr 17, 2018 at 3:33 PM, Laurent Dufour >> <lduf...@linux.vnet.ibm.com> wrote: >>> From: Peter Zijlstra <pet...@infradead.org> >>> [...] >>> >>> - vma = find_vma(mm, address); >>> + if (!vma || !can_reuse_spf_vma(vma, address)) >>> + vma = find_vma(mm, address); >> >> Is there a measurable benefit from reusing the vma? >> >> Dropping the vma reference unconditionally after speculative page >> fault handling gets rid of the implicit state when "vma != NULL" >> (increased ref-count). I found it a bit confusing to follow. > > I do agree, this is quite confusing. My initial goal was to be able to reuse > the VMA in the case a protection key error was detected, but it's not really > necessary on x86 since we know at the beginning of the fault operation that > protection key are in the loop. This is not the case on ppc64 but I couldn't > find a way to easily rely on the speculatively fetched VMA neither, so for > protection keys, this didn't help. > > Regarding the measurable benefit of reusing the fetched vma, I did further > tests using will-it-scale/page_fault2_threads test, and I'm no more really > convince that this worth the added complexity. I think I'll drop the patch > "mm: > speculative page fault handler return VMA" of the series, and thus remove the > call to can_reuse_spf_vma(). Makes sense. Thanks for giving this a go. Punit [...]
