From: Dave Hansen <dave.hansen@intel.com>
To: "Huang, Ying" <ying.huang@intel.com>,
Andrew Morton <akpm@linux-foundation.org>
Cc: tim.c.chen@intel.com, andi.kleen@intel.com, aaron.lu@intel.com,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Hugh Dickins <hughd@google.com>, Shaohua Li <shli@kernel.org>,
Minchan Kim <minchan@kernel.org>, Rik van Riel <riel@redhat.com>,
Mel Gorman <mgorman@techsingularity.net>,
Tejun Heo <tj@kernel.org>, Wu Fengguang <fengguang.wu@intel.com>
Subject: Re: [RFC] mm: Don't use radix tree writeback tags for pages in swap cache
Date: Tue, 9 Aug 2016 09:34:35 -0700 [thread overview]
Message-ID: <57AA061B.2050002@intel.com> (raw)
In-Reply-To: <1470759443-9229-1-git-send-email-ying.huang@intel.com>
On 08/09/2016 09:17 AM, Huang, Ying wrote:
> File pages uses a set of radix tags (DIRTY, TOWRITE, WRITEBACK) to
> accelerate finding the pages with the specific tag in the the radix tree
> during writing back an inode. But for anonymous pages in swap cache,
> there are no inode based writeback. So there is no need to find the
> pages with some writeback tags in the radix tree. It is no necessary to
> touch radix tree writeback tags for pages in swap cache.
Seems simple enough. Do we do any of this unnecessary work for the
other radix tree tags? If so, maybe we should just fix this once and
for all. Could we, for instance, WARN_ONCE() in radix_tree_tag_set() if
it sees a swap mapping get handed in there?
In any case, I think the new !PageSwapCache(page) check either needs
commenting, or a common helper for the two sites that you can comment.
> With this patch, the swap out bandwidth improved 22.3% in vm-scalability
> swap-w-seq test case with 8 processes on a Xeon E5 v3 system, because of
> reduced contention on swap cache radix tree lock. To test sequence swap
> out, the test case uses 8 processes sequentially allocate and write to
> anonymous pages until RAM and part of the swap device is used up.
What was the swap device here, btw? What is the actual bandwidth
increase you are seeing? Is it 1MB/s -> 1.223MB/s? :)
--
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>
next prev parent reply other threads:[~2016-08-09 16:34 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-09 16:17 Huang, Ying
2016-08-09 16:34 ` Dave Hansen [this message]
2016-08-09 17:00 ` Huang, Ying
2016-08-24 16:12 ` Huang, Ying
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=57AA061B.2050002@intel.com \
--to=dave.hansen@intel.com \
--cc=aaron.lu@intel.com \
--cc=akpm@linux-foundation.org \
--cc=andi.kleen@intel.com \
--cc=fengguang.wu@intel.com \
--cc=hughd@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@techsingularity.net \
--cc=minchan@kernel.org \
--cc=riel@redhat.com \
--cc=shli@kernel.org \
--cc=tim.c.chen@intel.com \
--cc=tj@kernel.org \
--cc=ying.huang@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