Re: [RFC][PATCH 6/8] mm: handle_speculative_fault()
From: Peter Zijlstra
Date: Thu Jan 07 2010 - 16:50:15 EST
On Thu, 2010-01-07 at 10:15 -0800, Linus Torvalds wrote:
>
> On Thu, 7 Jan 2010, Peter Zijlstra wrote:
> >
> > Well, with that sync_vma() thing I posted the other day all the
> > speculative page fault needs is a write to current->fault_vma, the ptl
> > and an O(nr_threads) loop on unmap() for file vmas -- aside from writing
> > the pte itself of course.
>
> How do you handle the race of
>
> fault handler: munmap
>
> look up vma without locks
>
> .. interrupt happens or
> something delays things ..
> remove the vma from the list
> sync_vma()
>
> current->fault_vma = vma
>
> etc?
>
> Maybe I'm missing something, but quite frankly, the above looks pretty
> damn fundamental. Something needs to take a lock. If you get rid of the
> mmap_sem, you need to replace it with another lock.
>
> There's no sane way to "look up vma and atomically mark it as busy"
> without locks. You can do it with extra work, ie something like
>
> look up vma without locks
> current->fault_vma = vma
> smp_mb();
> check that the vma is still on the list
>
> (with he appropriate barriers on the munmap side too, of course) where you
> avoid the lock by basically turning it into an ordering problem, but it
> ends up being pretty much as expensive anyway for single threads.
As expensive for single threads is just fine with me, as long as we get
cheaper with lots of threads.
I basically did the above revalidation with seqlocks, we lookup the vma,
mark it busy and revalidate the vma sequence count.
> And for lots and lots of threads, you now made that munmap be pretty
> expensive.
Yeah, I really hate that part too, trying hard to come up with something
smarter but my brain isn't yet co-operating :-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/