[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <51926B64.5040005@sr71.net>
Date: Tue, 14 May 2013 09:50:44 -0700
From: Dave Hansen <dave@...1.net>
To: Mel Gorman <mgorman@...e.de>
CC: linux-mm@...ck.org, linux-kernel@...r.kernel.org,
akpm@...ux-foundation.org, tim.c.chen@...ux.intel.com
Subject: Re: [RFC][PATCH 6/7] use __remove_mapping_batch() in shrink_page_list()
On 05/14/2013 09:05 AM, Mel Gorman wrote:
> This helper seems overkill. Why not just have batch_mapping in
> shrink_page_list() that is set when the first page is added to the
> batch_for_mapping_removal and defer the decision to drain until after the
> page mapping has been looked up?
>
> struct address_space *batch_mapping = NULL;
>
> .....
>
> mapping = page_mapping(page);
> if (!batch_mapping)
> batch_mapping = mapping;
>
> if (!list_empty(&batch_for_mapping_removal) && mapping != batch_mapping) {
> nr_reclaimed += __remove_mapping_batch(....);
> batch_mapping = mapping;
> }
I was trying to avoid doing the batch drain while holding lock_page() on
an unrelated page. But, now that I think about it, that was probably
unsafe anyway. The page could have been truncated out of the mapping
since it *was* before lock_page().
I think I was also trying to save adding another local variable, but
you're right that it's overkill. I'll fix it up.
--
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