From: Joel Schopp <jschopp@austin.ibm.com>
To: Christoph Lameter <clameter@engr.sgi.com>
Cc: lhms-devel@lists.sourceforge.net, linux-mm@vger.kernel.org,
akpm@osdl.org
Subject: Re: [Lhms-devel] [PATCH] Page eviction support in vmscan.c
Date: Thu, 13 Oct 2005 17:20:58 -0500 [thread overview]
Message-ID: <434EDDCA.9010001@austin.ibm.com> (raw)
In-Reply-To: <Pine.LNX.4.62.0510131109210.14810@schroedinger.engr.sgi.com>
> This patch adds functions that allow the eviction of pages to swap space.
> Page eviction may be useful to migrate pages, suspend programs or for
> ummapping single pages (useful for faulty pages or pages with soft ECC
> failures)
I'm curious what use motivated you to write it. I think for migration
it would usually make more sense to let the swapper free up LRU memory
and then do a memory to memory migration. But I'm not really a
migration expert
> swapout_pages does its best to swapout the pages and does multiple passes over the list.
> However, swapout_pages may not be able to evict all pages for a variety of reasons.
Have you thought about using this in combination with the fragmentation
avoidance patches Mel has been posting? __GFP_USER flag that adds would
go a long way toward determining what can and can't be swapped out. We
use that for migration with great success. I'd assume the criteria for
swapout and migration are pretty similar.
> /*
> + * Swapout evicts the pages on the list to swap space.
> + * This is essentially a dumbed down version of shrink_list
Have you thought about reusing code from shrink list without duplicating
it? That is a whole lot of duplicated code to maintain twice.
> + if (PageDirty(page)) {
> + /* Page is dirty, try to write it out here */
> + switch(pageout(page, mapping)) {
> + case PAGE_KEEP:
> + case PAGE_ACTIVATE:
> + goto retry_later_locked;
> + case PAGE_SUCCESS:
> + goto retry_later;
> + case PAGE_CLEAN:
> + ; /* try to free the page below */
> + }
> + }
Tabs vs spaces?
> +
> + list_del(&page->lru);
> + unlock_page(page);
> + put_page(page);
> + continue;
Tabs vs spaces?
--
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>
next prev parent reply other threads:[~2005-10-13 22:38 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-10-13 18:13 [PATCH] Page eviction support in vmscan.c Christoph Lameter
2005-10-13 22:20 ` Joel Schopp [this message]
[not found] ` <Pine.LNX.4.62.0510131524490.17853@schroedinger.engr.sgi.com>
2005-10-17 2:59 ` [Lhms-devel] " KAMEZAWA Hiroyuki
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=434EDDCA.9010001@austin.ibm.com \
--to=jschopp@austin.ibm.com \
--cc=akpm@osdl.org \
--cc=clameter@engr.sgi.com \
--cc=lhms-devel@lists.sourceforge.net \
--cc=linux-mm@vger.kernel.org \
/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.