From: Mel Gorman <mel@csn.ul.ie>
To: Shaohua Li <shaohua.li@intel.com>
Cc: lkml <linux-kernel@vger.kernel.org>,
Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [RFC] move free page back to MIGRATE_MOVABLE?
Date: Mon, 17 Dec 2007 10:44:53 +0000 [thread overview]
Message-ID: <20071217104452.GA3778@csn.ul.ie> (raw)
In-Reply-To: <1197523199.3410.1.camel@sli10-desk.sh.intel.com>
On (13/12/07 13:19), Shaohua Li didst pronounce:
> pages are MIGRATE_MOVABLE initially, and fallback to other types. If the
> pages are freed, I wonder why not move them back to MIGRATE_MOVABLE.
Because there is no need, if a MIGRATE_MOVABLE allocation needs more pages,
they will be acquired during fallback which always steals the largest
block. Lets say that a MIGRATE_UNMOVABLE block is freed and it is larger
than pageblock_order. The next MIGRATE_MOVABLE allocation will find it during
fallback if necessary.
> This, for example, can help memory remove.
>
I don't see how. When hot-removing, MIGRATE_MOVABLE blocks are considered
possible to remove but they are also considered movable if the pages are free.
> Thanks,
> Shaohua
>
> Index: linux/mm/page_alloc.c
> ===================================================================
> --- linux.orig/mm/page_alloc.c 2007-12-13 11:44:36.000000000 +0800
> +++ linux/mm/page_alloc.c 2007-12-13 12:04:59.000000000 +0800
> @@ -386,6 +386,9 @@ static inline int page_is_buddy(struct p
> return 0;
> }
>
> +int move_freepages(struct zone *zone,
> + struct page *start_page, struct page *end_page,
> + int migratetype);
> /*
> * Freeing function for a buddy system allocator.
> *
> @@ -446,6 +449,17 @@ static inline void __free_one_page(struc
> list_add(&page->lru,
> &zone->free_area[order].free_list[migratetype]);
> zone->free_area[order].nr_free++;
> +
> + if (order >= pageblock_order && migratetype != MIGRATE_MOVABLE) {
> + struct page *tmp = page;
> +
> + move_freepages(zone, page, page + (1 << order) - 1, MIGRATE_MOVABLE);
> +
This is unnecessary and affects a commonly used path. If a MOVABLE allocation
needs more pages later, it will find the large free block during fallback.
> + while (tmp < page + (1 << order)) {
> + set_pageblock_migratetype(tmp, MIGRATE_MOVABLE);
> + tmp += pageblock_nr_pages;
> + }
> + }
> }
>
> static inline int free_pages_check(struct page *page)
>
--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab
prev parent reply other threads:[~2007-12-17 10:45 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-12-13 5:19 Shaohua Li
2007-12-17 10:44 ` Mel Gorman [this message]
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=20071217104452.GA3778@csn.ul.ie \
--to=mel@csn.ul.ie \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=shaohua.li@intel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®