lkml.org 
[lkml]   [2009]   [Dec]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [mm][RFC][PATCH 0/11] mm accessor updates.
    On Thu, Dec 17, 2009 at 12:01:55AM +0100, Peter Zijlstra wrote:
    > On Wed, 2009-12-16 at 10:27 -0600, Christoph Lameter wrote:
    > > On Wed, 16 Dec 2009, Andi Kleen wrote:
    > >
    > > > > Do you have alternative recommendation rather than wrapping all accesses by
    > > > > special functions ?
    > > >
    > > > Work out what changes need to be done for ranged mmap locks and do them all
    > > > in one pass.
    > >
    > > Locking ranges is already possible through the split ptlock and
    > > could be enhanced through placing locks in the vma structures.
    > >
    > > That does nothing solve the basic locking issues of mmap_sem. We need
    > > Kame-sans abstraction layer. A vma based lock or a ptlock still needs to
    > > ensure that the mm struct does not vanish while the lock is held.
    >
    > It should, you shouldn't be able to remove a mm while there's still
    > vma's around, and you shouldn't be able to remove a vma when there's
    > still pagetables around. And if you rcu-free all of them you're stable
    > enough for lots of speculative behaviour.

    Yes, the existing reference counts are probably sufficient for all that.

    Still need list stability.

    > As for per-vma locks, those are pretty much useless too, there's plenty
    > applications doing lots of work on a few very large vmas.

    True.
    -Andi

    --
    ak@linux.intel.com -- Speaking for myself only.


    \
     
     \ /
      Last update: 2009-12-17 09:43    [W:4.024 / U:0.272 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site