lkml.org 
[lkml]   [2006]   [Jan]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: smp race fix between invalidate_inode_pages* and do_no_page
    Andrea Arcangeli <andrea@suse.de> wrote:
    >
    > On Wed, Jan 11, 2006 at 12:51:34AM -0800, Andrew Morton wrote:
    > > Andrea Arcangeli <andrea@suse.de> wrote:
    > > >
    > > > On Wed, Jan 11, 2006 at 03:08:31PM +1100, Nick Piggin wrote:
    > > > > I'd be inclined to think a lock_page is not a big SMP scalability
    > > > > problem because the struct page's cacheline(s) will be written to
    > > > > several times in the process of refcounting anyway. Such a workload
    > > > > would also be running into tree_lock as well.
    > > >
    > > > I seem to recall you wanted to make the tree_lock a readonly lock for
    > > > readers for the exact same scalability reason? do_no_page is quite a
    > > > fast path for the tree lock too. But I totally agree the unavoidable is
    > > > the atomic_inc though, good point, so it worth more to remove the
    > > > tree_lock than to remove the page lock, the tree_lock can be avoided the
    > > > atomic_inc on page->_count not.
    > > >
    > > > The other bonus that makes this attractive is that then we can drop the
    > > > *whole* vm_truncate_count mess... vm_truncate_count and
    > > > inode->trunate_count exists for the only single reason that do_no_page
    > > > must not map into the pte a page that is under truncation.
    > >
    > > I think you'll find this hard - filemap_nopage() is the first to find the
    > > page but we need lock coverage up in do_no_page(). So the ->nopage
    > > protocol will need to be changed to "must return with the page locked". Or
    > > we add a new ->nopage_locked and call that if the vm_ops implements it.
    >
    > Can't we avoid to change the protocol and use lock_page in do_no_page
    > instead?

    Confused. do_no_page() doesn't have a page to lock until it has called
    ->nopage.

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2006-01-11 10:09    [W:0.024 / U:59.452 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site