All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Hansen <dave@sr71.net>
To: Mel Gorman <mgorman@suse.de>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	akpm@linux-foundation.org, tim.c.chen@linux.intel.com
Subject: Re: [RFC][PATCH 6/7] use __remove_mapping_batch() in shrink_page_list()
Date: Tue, 14 May 2013 09:50:44 -0700	[thread overview]
Message-ID: <51926B64.5040005@sr71.net> (raw)
In-Reply-To: <20130514160541.GX11497@suse.de>

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, 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>

WARNING: multiple messages have this Message-ID (diff)
From: Dave Hansen <dave@sr71.net>
To: Mel Gorman <mgorman@suse.de>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	akpm@linux-foundation.org, tim.c.chen@linux.intel.com
Subject: Re: [RFC][PATCH 6/7] use __remove_mapping_batch() in shrink_page_list()
Date: Tue, 14 May 2013 09:50:44 -0700	[thread overview]
Message-ID: <51926B64.5040005@sr71.net> (raw)
In-Reply-To: <20130514160541.GX11497@suse.de>

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.

  reply	other threads:[~2013-05-14 16:50 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-07 21:19 [RFC][PATCH 0/7] mm: Batch page reclamation under shink_page_list Dave Hansen
2013-05-07 21:19 ` Dave Hansen
2013-05-07 21:19 ` [RFC][PATCH 1/7] defer clearing of page_private() for swap cache pages Dave Hansen
2013-05-07 21:19   ` Dave Hansen
2013-05-09 22:07   ` Seth Jennings
2013-05-09 22:07     ` Seth Jennings
2013-05-09 22:19     ` Dave Hansen
2013-05-09 22:19       ` Dave Hansen
2013-05-10  9:26     ` Michal Hocko
2013-05-10  9:26       ` Michal Hocko
2013-05-10 14:01       ` Seth Jennings
2013-05-10 14:01         ` Seth Jennings
2013-05-14 14:55   ` Mel Gorman
2013-05-14 14:55     ` Mel Gorman
2013-05-07 21:19 ` [RFC][PATCH 2/7] make 'struct page' and swp_entry_t variants of swapcache_free() Dave Hansen
2013-05-07 21:19   ` Dave Hansen
2013-05-14 15:00   ` Mel Gorman
2013-05-14 15:00     ` Mel Gorman
2013-05-07 21:19 ` [RFC][PATCH 3/7] break up __remove_mapping() Dave Hansen
2013-05-07 21:19   ` Dave Hansen
2013-05-14 15:22   ` Mel Gorman
2013-05-14 15:22     ` Mel Gorman
2013-05-07 21:20 ` [RFC][PATCH 4/7] break out mapping "freepage" code Dave Hansen
2013-05-07 21:20   ` Dave Hansen
2013-05-14 15:26   ` Mel Gorman
2013-05-14 15:26     ` Mel Gorman
2013-05-07 21:20 ` [RFC][PATCH 5/7] create __remove_mapping_batch() Dave Hansen
2013-05-07 21:20   ` Dave Hansen
2013-05-09 22:13   ` Seth Jennings
2013-05-09 22:13     ` Seth Jennings
2013-05-09 22:18     ` Dave Hansen
2013-05-09 22:18       ` Dave Hansen
2013-05-14 15:51   ` Mel Gorman
2013-05-14 15:51     ` Mel Gorman
2013-05-16 17:14     ` Dave Hansen
2013-05-16 17:14       ` Dave Hansen
2013-05-07 21:20 ` [RFC][PATCH 6/7] use __remove_mapping_batch() in shrink_page_list() Dave Hansen
2013-05-07 21:20   ` Dave Hansen
2013-05-14 16:05   ` Mel Gorman
2013-05-14 16:05     ` Mel Gorman
2013-05-14 16:50     ` Dave Hansen [this message]
2013-05-14 16:50       ` Dave Hansen
2013-05-07 21:20 ` [RFC][PATCH 7/7] drain batch list during long operations Dave Hansen
2013-05-07 21:20   ` Dave Hansen
2013-05-07 23:56   ` Dave Hansen
2013-05-07 23:56     ` Dave Hansen
2013-05-08  0:42   ` Tim Chen
2013-05-08  0:42     ` Tim Chen
2013-05-14 16:08   ` Mel Gorman
2013-05-14 16:08     ` Mel Gorman

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=51926B64.5040005@sr71.net \
    --to=dave@sr71.net \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mgorman@suse.de \
    --cc=tim.c.chen@linux.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.