lkml.org 
[lkml]   [2010]   [Jan]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC][PATCH 6/8] mm: handle_speculative_fault()


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.

And for lots and lots of threads, you now made that munmap be pretty
expensive.

Linus


\
 
 \ /
  Last update: 2010-01-07 19:19    [W:0.515 / U:0.108 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site