[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20100309095342.GD8653@laptop>
Date: Tue, 9 Mar 2010 20:53:42 +1100
From: Nick Piggin <npiggin@...e.de>
To: Mel Gorman <mel@....ul.ie>
Cc: linux-mm@...ck.org,
Christian Ehrhardt <ehrhardt@...ux.vnet.ibm.com>,
Chris Mason <chris.mason@...cle.com>,
Jens Axboe <jens.axboe@...cle.com>,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/3] page-allocator: Check zone pressure when batch of
pages are freed
Cool, you found this doesn't hurt performance too much?
Can't you remove the check from the reclaim code now? (The check
here should give a more timely wait anyway)
This is good because it should eliminate most all cases of extra
waiting. I wonder if you've also thought of doing the check in the
allocation path too as we were discussing? (this would give a better
FIFO behaviour under memory pressure but I could easily agree it is not
worth the cost)
On Mon, Mar 08, 2010 at 11:48:22AM +0000, Mel Gorman wrote:
> When a batch of pages have been freed to the buddy allocator, it is possible
> that it is enough to push a zone above its watermarks. This patch puts a
> check in the free path for zone pressure. It's in a common path but for
> the most part, it should only be checking if a linked list is empty and
> have minimal performance impact.
>
> Signed-off-by: Mel Gorman <mel@....ul.ie>
> ---
> mm/page_alloc.c | 3 +++
> 1 files changed, 3 insertions(+), 0 deletions(-)
>
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index 1383ff9..3c8e8b7 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -562,6 +562,9 @@ static void free_pcppages_bulk(struct zone *zone, int count,
> } while (--count && --batch_free && !list_empty(list));
> }
> spin_unlock(&zone->lock);
> +
> + /* A batch of pages have been freed so check zone pressure */
> + check_zone_pressure(zone);
> }
>
> static void free_one_page(struct zone *zone, struct page *page, int order,
> --
> 1.6.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists