All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
To: Nick Piggin <npiggin@suse.de>
Cc: linux-mm <linux-mm@kvack.org>, Rik van Riel <riel@redhat.com>
Subject: RFC:  Noreclaim with "Keep Mlocked Pages off the LRU"
Date: Fri, 24 Aug 2007 16:43:38 -0400	[thread overview]
Message-ID: <1187988218.5869.64.camel@localhost> (raw)
In-Reply-To: <20070823041137.GH18788@wotan.suse.de>

For your weekend reading pleasure [:-)]

I have reworked your "move mlocked pages off LRU" atop my "noreclaim
infrastructure" that keeps non-reclaimable pages [mlocked, swap-backed
but no swap space, excessively long anon_vma list] on a separate
noreclaim LRU list--more or less ignored by vmscan.  To do this, I had
to <mumble>add<mumble>a new<mumble>mlock_count member<mumble>to
the<mumble>page struct.  This brings the size of the page struct to a
nice, round 64 bytes.  The mlock_count member and [most of] the
noreclaim-mlocked-pages work now depends on CONFIG_NORECLAIM_MLOCK which
depends on CONFIG_NORECLAIM.  Currently,  the entire noreclaim
infrastructure is only supported on 64bit archs because I'm using a
higher order bit [~30] for the PG_noreclaim flag.

Using the noreclaim infrastructure does seem to simplify the "keep
mlocked pages off the LRU" code tho'.  All of the isolate_lru_page(),
move_to_lru(), ... functions have been taught about the noreclaim list,
so many places don't need changes.  That being said, I really not sure
I've covered all of the bases here...

Now, mlocked pages come back off the noreclaim list nicely when the last
mlock reference goes away--assuming I have the counting correct.
However, pages marked non-reclaimable for other reasons--no swap
available, excessive anon_vma ref count--can languish there
indefinitely.   At some point, perhaps vmscan could be taught to do a
slow background scan of the noreclaim list [making it more like
"slo-reclaim"--but we already have that :-)] when swap is added and we
have unswappable pages on the list.  Currently, I don't keep track of
the various reasons for the no-reclaim pages, but that could be added.  

Rik Van Riel mentions, on his VM wiki page that a background scan might
be useful to age pages actively [clock hand, anyone?], so I might be
able to piggyback on that, or even prototype it at some point.   In the
meantime, I'm going to add a scan of the noreclaim list manually
triggered by a temporary sysctl.

Anyway, if anyone is interested, the patches are in a gzip'd tarball in:

http://free.linux.hp.com/~lts/Patches/Noreclaim/

Cursory functional testing with memtoy shows that it basically works.
I've started a moderately stressful workload for the weekend.  We'll see
how it goes.

Cheers,
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>

  parent reply	other threads:[~2007-08-24 20:43 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-08-23  4:11 vmscan-give-referenced-active-and-unmapped-pages-a-second-trip-around-the-lru Nick Piggin
2007-08-23  7:15 ` vmscan-give-referenced-active-and-unmapped-pages-a-second-trip-around-the-lru Andrew Morton
2007-08-23  9:07   ` vmscan-give-referenced-active-and-unmapped-pages-a-second-trip-around-the-lru Nick Piggin
2007-08-23 11:48     ` vmscan-give-referenced-active-and-unmapped-pages-a-second-trip-aroun d-the-lru Andrea Arcangeli
2007-08-24 20:43 ` Lee Schermerhorn [this message]
2007-08-27  1:35   ` RFC: Noreclaim with "Keep Mlocked Pages off the LRU" Nick Piggin
2007-08-27 14:34     ` Lee Schermerhorn
2007-08-27 15:44       ` Christoph Hellwig
2007-08-27 23:51         ` Nick Piggin
2007-08-28 12:29           ` Christoph Hellwig
2007-08-28  0:06       ` Nick Piggin
2007-08-28 14:52         ` Lee Schermerhorn
2007-08-28 21:54           ` Christoph Lameter
2007-08-29 14:40             ` Lee Schermerhorn
2007-08-29 17:39               ` Christoph Lameter
2007-08-30  0:09                 ` Rik van Riel
2007-08-30 14:49                   ` Lee Schermerhorn
2007-08-29  4:38           ` Nick Piggin
2007-08-30 16:34             ` Lee Schermerhorn

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=1187988218.5869.64.camel@localhost \
    --to=lee.schermerhorn@hp.com \
    --cc=linux-mm@kvack.org \
    --cc=npiggin@suse.de \
    --cc=riel@redhat.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.