From: mel@skynet.ie (Mel Gorman)
To: Christoph Lameter <clameter@sgi.com>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
kamezawa.hiroyu@jp.fujitsu.com
Subject: Re: [PATCH 5/7] Introduce a means of compacting memory within a zone
Date: Tue, 19 Jun 2007 17:36:11 +0100 [thread overview]
Message-ID: <20070619163611.GD17109@skynet.ie> (raw)
In-Reply-To: <Pine.LNX.4.64.0706181010030.4751@schroedinger.engr.sgi.com>
On (18/06/07 10:18), Christoph Lameter didst pronounce:
> On Mon, 18 Jun 2007, Mel Gorman wrote:
>
> > + /* Isolate free pages. This assumes the block is valid */
> > + for (; blockpfn < end_pfn; blockpfn++) {
> > + struct page *page;
> > + int isolated, i;
> > +
> > + if (!pfn_valid_within(blockpfn))
> > + continue;
> > +
> > + page = pfn_to_page(blockpfn);
> > + if (!PageBuddy(page))
> > + continue;
>
> The name PageBuddy is getting to be misleading. Maybe rename this to
> PageFree or so?
>
That would be suprisingly ambiguous. per-cpu pages are free pages but are not
PageBuddy pages. In this case, I really mean a PageBuddy page, not a free page.
> > +
> > + /* Found a free page, break it into order-0 pages */
> > + isolated = split_free_page(page);
> > + total_isolated += isolated;
> > + for (i = 0; i < isolated; i++) {
> > + list_add(&page->lru, freelist);
> > + page++;
> > + }
>
> Why do you need to break them all up? Easier to coalesce later?
>
They are broken up because migration currently works on order-0 pages.
It is easier to break them up now for compaction_alloc() to give out one
at a time than trying to figure out how to split them up later.
> > +/* Returns 1 if the page is within a block suitable for migration to */
> > +static int pageblock_migratable(struct page *page)
> > +{
> > + /* If the page is a large free page, then allow migration */
> > + if (PageBuddy(page) && page_order(page) >= pageblock_order)
> > + return 1;
>
> if (PageSlab(page) && page->slab->ops->kick) {
> migratable slab
> }
>
> if (page table page) {
> migratable page table page?
> }
>
> etc?
>
Not quite. pageblock_migratable() is telling if this block is suitable for
taking free pages from so movable pages can be migrated there. Right now
that means checking if there are enough free pages that the whole block
becomes MOVABLE or if the block is already being used for movable pages.
The block could become movable if the decision was made to kick out slab
pages that are located towards the end of the zone. If page tables
become movable, then they would need to be identified here but that is
not the case.
The pageblock_migratable() function is named so that this decision can
be easily revisited in one place.
> > + /* Try isolate the page */
> > + if (locked_isolate_lru_page(zone, page, migratelist) == 0)
> > + isolated++;
>
> Support for other ways of migrating a page?
>
When other mechanisms exist, they would be added here. Right now,
isolate_lru_page() is the only one I am aware of.
> > +static int compact_zone(struct zone *zone, struct compact_control *cc)
> > +{
> > + int ret = COMPACT_INCOMPLETE;
> > +
> > + /* Setup to move all movable pages to the end of the zone */
> > + cc->migrate_pfn = zone->zone_start_pfn;
> > + cc->free_pfn = cc->migrate_pfn + zone->spanned_pages;
> > + cc->free_pfn &= ~(pageblock_nr_pages-1);
> > +
> > + for (; ret == COMPACT_INCOMPLETE; ret = compact_finished(zone, cc)) {
> > + isolate_migratepages(zone, cc);
> > +
> > + if (!cc->nr_migratepages)
> > + continue;
> > +
> > + /* Isolate free pages if necessary */
> > + if (cc->nr_freepages < cc->nr_migratepages)
> > + isolate_freepages(zone, cc);
> > +
> > + /* Stop compacting if we cannot get enough free pages */
> > + if (cc->nr_freepages < cc->nr_migratepages)
> > + break;
> > +
> > + migrate_pages(&cc->migratepages, compaction_alloc,
> > + (unsigned long)cc);
>
> You do not need to check the result of migration? Page migration is a best
> effort that may fail.
>
You're right. I used to check it for debugging purposes to make sure migration
was actually occuring. It is not unusual still for a fair number of pages
to fail to migrate. migration already uses a retry logic and I shouldn't
be replicating it.
More importantly, by leaving the pages on the migratelist, I potentially
retry the same migrations over and over again wasting time and effort not
to mention that I keep pages isolated for much longer than necessary and
that could cause stalling problems. I should be calling putback_lru_pages()
when migrate_pages() tells me it failed to migrate pages.
I'll revisit this one. Thanks
> Looks good otherwise.
>
> Acked-by: Christoph Lameter <clameter@sgi.com>
--
--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab
--
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:[~2007-06-19 16:36 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-06-18 9:28 [PATCH 0/7] Memory Compaction v2 Mel Gorman
2007-06-18 9:28 ` [PATCH 1/7] KAMEZAWA Hiroyuki hot-remove patches Mel Gorman
2007-06-18 16:56 ` Christoph Lameter
2007-06-19 15:52 ` Mel Gorman
2007-06-18 9:29 ` [PATCH 2/7] Allow CONFIG_MIGRATION to be set without CONFIG_NUMA Mel Gorman
2007-06-18 17:04 ` Christoph Lameter
2007-06-19 15:59 ` Mel Gorman
2007-06-18 9:29 ` [PATCH 3/7] Introduce isolate_lru_page_nolock() as a lockless version of isolate_lru_page() Mel Gorman
2007-06-18 17:05 ` Christoph Lameter
2007-06-18 9:29 ` [PATCH 4/7] Provide metrics on the extent of fragmentation in zones Mel Gorman
2007-06-18 17:07 ` Christoph Lameter
2007-06-18 9:30 ` [PATCH 5/7] Introduce a means of compacting memory within a zone Mel Gorman
2007-06-18 17:18 ` Christoph Lameter
2007-06-19 16:36 ` Mel Gorman [this message]
2007-06-19 19:20 ` Christoph Lameter
2007-06-19 12:54 ` Yasunori Goto
2007-06-19 16:49 ` Mel Gorman
2007-06-18 9:30 ` [PATCH 6/7] Add /proc/sys/vm/compact_node for the explicit compaction of a node Mel Gorman
2007-06-18 9:30 ` [PATCH 7/7] Compact memory directly by a process when a high-order allocation fails Mel Gorman
2007-06-18 17:22 ` Christoph Lameter
2007-06-19 16:50 ` Mel Gorman
2007-06-21 12:28 ` Andrew Morton
2007-06-21 13:26 ` Mel Gorman
2007-06-18 17:24 ` [PATCH 0/7] Memory Compaction v2 Christoph Lameter
2007-06-19 16:58 ` Mel Gorman
2007-06-19 19:22 ` Christoph Lameter
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=20070619163611.GD17109@skynet.ie \
--to=mel@skynet.ie \
--cc=clameter@sgi.com \
--cc=kamezawa.hiroyu@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox