mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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

      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®