From: Andrew Morton <akpm@linux-foundation.org>
To: Tim Chen <tim.c.chen@linux.intel.com>
Cc: Mel Gorman <mel@csn.ul.ie>, Minchan Kim <minchan@kernel.org>,
Johannes Weiner <hannes@cmpxchg.org>,
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
Andrea Arcangeli <aarcange@redhat.com>,
David Rientjes <rientjes@google.com>,
Michal Hocko <mhocko@suse.cz>,
Xiao Guangrong <xiaoguangrong@linux.vnet.ibm.com>,
Paul Gortmaker <paul.gortmaker@windriver.com>,
Matthew Wilcox <willy@linux.intel.com>,
"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
Andi Kleen <ak@linux.intel.com>,
linux-mm@kvack.org, linux-kernel <linux-kernel@vger.kernel.org>,
Alex Shi <alex.shi@intel.com>,
Fengguang Wu <fengguang.wu@intel.com>
Subject: Re: [PATCH 0/3 v2] mm: Batch page reclamation under shink_page_list
Date: Wed, 12 Sep 2012 12:27:58 -0700 [thread overview]
Message-ID: <20120912122758.ad15e10f.akpm@linux-foundation.org> (raw)
In-Reply-To: <1347293960.9977.70.camel@schen9-DESK>
On Mon, 10 Sep 2012 09:19:20 -0700
Tim Chen <tim.c.chen@linux.intel.com> wrote:
> This is the second version of the patch series. Thanks to Matthew Wilcox
> for many valuable suggestions on improving the patches.
>
> To do page reclamation in shrink_page_list function, there are two
> locks taken on a page by page basis. One is the tree lock protecting
> the radix tree of the page mapping and the other is the
> mapping->i_mmap_mutex protecting the mapped
> pages. I try to batch the operations on pages sharing the same lock
> to reduce lock contentions. The first patch batch the operations protected by
> tree lock while the second and third patch batch the operations protected by
> the i_mmap_mutex.
>
> I managed to get 14% throughput improvement when with a workload putting
> heavy pressure of page cache by reading many large mmaped files
> simultaneously on a 8 socket Westmere server.
That sounds good, although more details on the performance changes
would be appreciated - after all, that's the entire point of the
patchset.
And we shouldn't only test for improvements - we should also test for
degradation. What workloads might be harmed by this change? I'd suggest
- a single process which opens N files and reads one page from each
one, then repeats. So there are no contiguous LRU pages which share
the same ->mapping. Get some page reclaim happening, measure the
impact.
- The batching means that we now do multiple passes over pageframes
where we used to do things in a single pass. Walking all those new
page lists will be expensive if they are lengthy enough to cause L1
cache evictions.
What would be a test for this? A simple, single-threaded walk
through a file, I guess?
Mel's review comments were useful, thanks.
--
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: Andrew Morton <akpm@linux-foundation.org>
To: Tim Chen <tim.c.chen@linux.intel.com>
Cc: Mel Gorman <mel@csn.ul.ie>, Minchan Kim <minchan@kernel.org>,
Johannes Weiner <hannes@cmpxchg.org>,
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
Andrea Arcangeli <aarcange@redhat.com>,
David Rientjes <rientjes@google.com>,
Michal Hocko <mhocko@suse.cz>,
Xiao Guangrong <xiaoguangrong@linux.vnet.ibm.com>,
Paul Gortmaker <paul.gortmaker@windriver.com>,
Matthew Wilcox <willy@linux.intel.com>,
"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
Andi Kleen <ak@linux.intel.com>,
linux-mm@kvack.org, linux-kernel <linux-kernel@vger.kernel.org>,
Alex Shi <alex.shi@intel.com>,
Fengguang Wu <fengguang.wu@intel.com>
Subject: Re: [PATCH 0/3 v2] mm: Batch page reclamation under shink_page_list
Date: Wed, 12 Sep 2012 12:27:58 -0700 [thread overview]
Message-ID: <20120912122758.ad15e10f.akpm@linux-foundation.org> (raw)
In-Reply-To: <1347293960.9977.70.camel@schen9-DESK>
On Mon, 10 Sep 2012 09:19:20 -0700
Tim Chen <tim.c.chen@linux.intel.com> wrote:
> This is the second version of the patch series. Thanks to Matthew Wilcox
> for many valuable suggestions on improving the patches.
>
> To do page reclamation in shrink_page_list function, there are two
> locks taken on a page by page basis. One is the tree lock protecting
> the radix tree of the page mapping and the other is the
> mapping->i_mmap_mutex protecting the mapped
> pages. I try to batch the operations on pages sharing the same lock
> to reduce lock contentions. The first patch batch the operations protected by
> tree lock while the second and third patch batch the operations protected by
> the i_mmap_mutex.
>
> I managed to get 14% throughput improvement when with a workload putting
> heavy pressure of page cache by reading many large mmaped files
> simultaneously on a 8 socket Westmere server.
That sounds good, although more details on the performance changes
would be appreciated - after all, that's the entire point of the
patchset.
And we shouldn't only test for improvements - we should also test for
degradation. What workloads might be harmed by this change? I'd suggest
- a single process which opens N files and reads one page from each
one, then repeats. So there are no contiguous LRU pages which share
the same ->mapping. Get some page reclaim happening, measure the
impact.
- The batching means that we now do multiple passes over pageframes
where we used to do things in a single pass. Walking all those new
page lists will be expensive if they are lengthy enough to cause L1
cache evictions.
What would be a test for this? A simple, single-threaded walk
through a file, I guess?
Mel's review comments were useful, thanks.
next prev parent reply other threads:[~2012-09-12 19:28 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-10 16:19 [PATCH 0/3 v2] mm: Batch page reclamation under shink_page_list Tim Chen
2012-09-10 16:19 ` Tim Chen
2012-09-11 5:36 ` Minchan Kim
2012-09-11 5:36 ` Minchan Kim
2012-09-13 16:08 ` Tim Chen
2012-09-13 16:08 ` Tim Chen
2012-09-12 19:27 ` Andrew Morton [this message]
2012-09-12 19:27 ` Andrew Morton
2012-09-12 23:44 ` Tim Chen
2012-09-12 23:44 ` Tim Chen
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=20120912122758.ad15e10f.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=aarcange@redhat.com \
--cc=ak@linux.intel.com \
--cc=alex.shi@intel.com \
--cc=fengguang.wu@intel.com \
--cc=hannes@cmpxchg.org \
--cc=kamezawa.hiroyu@jp.fujitsu.com \
--cc=kirill.shutemov@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mel@csn.ul.ie \
--cc=mhocko@suse.cz \
--cc=minchan@kernel.org \
--cc=paul.gortmaker@windriver.com \
--cc=rientjes@google.com \
--cc=tim.c.chen@linux.intel.com \
--cc=willy@linux.intel.com \
--cc=xiaoguangrong@linux.vnet.ibm.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.