linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andrea Arcangeli <andrea@suse.de>
To: Andrew Morton <akpm@osdl.org>
Cc: nickpiggin@yahoo.com.au, linux-kernel@vger.kernel.org, hugh@veritas.com
Subject: Re: smp race fix between invalidate_inode_pages* and do_no_page
Date: Wed, 11 Jan 2006 10:02:25 +0100	[thread overview]
Message-ID: <20060111090225.GY15897@opteron.random> (raw)
In-Reply-To: <20060111005134.3306b69a.akpm@osdl.org>

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? All we need to check before mailing out trying again is that
page->mapping is still there and then we have to set "page_mapping() ==
True" before unlocking (then the other side will have to block the pte
pte_lock running unmap_mapping_pages a second time with the page lock
held).

The main scary thing as far as I can tell, is the blocking lock_page. We
can't just do TryLockPage...

> But I agree it's a good change if we can pull it off.

Ok good thanks!

  reply	other threads:[~2006-01-11  9:02 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-12-13 19:37 smp race fix between invalidate_inode_pages* and do_no_page Andrea Arcangeli
2005-12-13 21:02 ` Andrew Morton
2005-12-13 21:14   ` Andrea Arcangeli
2005-12-16 13:51     ` Andrea Arcangeli
2006-01-10  6:24       ` Andrea Arcangeli
2006-01-10  6:48         ` Andrea Arcangeli
2006-01-11  4:08         ` Nick Piggin
2006-01-11  8:23           ` Andrea Arcangeli
2006-01-11  8:51             ` Andrew Morton
2006-01-11  9:02               ` Andrea Arcangeli [this message]
2006-01-11  9:06                 ` Andrew Morton
2006-01-11  9:13                   ` Andrea Arcangeli
2006-01-11 20:49                     ` Hugh Dickins
2006-01-11 21:05                       ` Andrew Morton
2006-01-13  7:35                       ` Nick Piggin
2006-01-13  7:47                         ` Andrew Morton
2006-01-13 10:37                           ` Nick Piggin
2006-03-31 12:36                             ` Andrea Arcangeli
2006-04-02  5:17                               ` Nick Piggin
2006-04-02  5:21                               ` Andrew Morton
2006-04-07 19:18                                 ` Hugh Dickins
2006-01-11  9:39                 ` Nick Piggin
2006-01-11  9:34             ` Nick Piggin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20060111090225.GY15897@opteron.random \
    --to=andrea@suse.de \
    --cc=akpm@osdl.org \
    --cc=hugh@veritas.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nickpiggin@yahoo.com.au \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).