Re: smp race fix between invalidate_inode_pages* and do_no_page

[Andrew Morton]

Andrea Arcangeli <andrea@xxxxxxx> 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.

But I agree it's a good change if we can pull it off.
-
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/