linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
To: Nick Piggin <nickpiggin@yahoo.com.au>
Cc: Christoph Lameter <clameter@sgi.com>,
	npiggin@suse.de, linux-mm@kvack.org
Subject: Re: 2.6.18-rc3-mm2: rcu radix tree patches break page migration
Date: Tue, 08 Aug 2006 10:53:19 -0400	[thread overview]
Message-ID: <1155048800.8184.23.camel@localhost> (raw)
In-Reply-To: <44D82508.9020409@yahoo.com.au>

On Tue, 2006-08-08 at 15:45 +1000, Nick Piggin wrote:
> Christoph Lameter wrote:
> 
> >On Tue, 8 Aug 2006, Nick Piggin wrote:
> >
> >
> >>Question: can you replace the lookup_slot with a regular lookup, then
> >>replace the pointer switch with a radix_tree_delete + radix_tree_insert
> >>and see if that works?
> >>
> >
> >Ahh... Okay that makes things work the right way.
> >
> >Does that mean we need to get rid of radix tree replaces in 
> >general?
> >
> 
> I think it just means that my lookup_slot has a bug somewhere. Also: good
> to know that I'm not corrupting anyones pagecache (except yours, and Lee's).

I saw this under heavy "auto-migration" of just anon pages during
parallel kernel builds:  "make -j32" on a 16cpu/4node numa system.  

The symptom I saw was when two tasks raced in do_swap_page to refault a
page that I had forcibly pushed to the swap cache [but still resident in
memory] to allow possible migrate on fault.  The loser of the race would
wait behind the page lock, holding a reference handed out by
find_get_page().  When it awakened, after the winner had migrated the
page, it would see that the page had been migrated out from under it,
release the ref and retry the lookup.  When it released the reference,
the count would go to zero, and the page would be freed.  It would
ultimately hit a BUG_ON in list_del() called from free_pages_bulk():
entry->prev->next != entry.

Now that the mbind() failure seems fixed, I'm rebasing my patches.  I
think I'll be able to reproduce this fairly regularly.

> 
> Let me work out what I'm doing wrong. In the meantime if you could send
> that patch to akpm as a fixup, that would keep you running. Thanks guys.

I'm willing to test anything you come up with.  I'll take a look at the
lookup, as well, code once I can reproduce the failure.

Lee

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2006-08-08 14:53 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-08-07 23:10 Christoph Lameter
2006-08-08  1:24 ` Nick Piggin
2006-08-08  3:42   ` Christoph Lameter
2006-08-08  5:45     ` Nick Piggin
2006-08-08 14:53       ` Lee Schermerhorn [this message]
2006-08-08 16:19       ` Christoph Lameter
2006-08-08 17:25         ` Andrew Morton
2006-08-08 17:52           ` Christoph Lameter
2006-08-09  1:39           ` 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=1155048800.8184.23.camel@localhost \
    --to=lee.schermerhorn@hp.com \
    --cc=clameter@sgi.com \
    --cc=linux-mm@kvack.org \
    --cc=nickpiggin@yahoo.com.au \
    --cc=npiggin@suse.de \
    /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