All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Huang\, Ying" <ying.huang@intel.com>
To: Mel Gorman <mgorman@techsingularity.net>
Cc: "Huang\, Ying" <ying.huang@intel.com>,
	Andrew Morton <akpm@linux-foundation.org>, <tim.c.chen@intel.com>,
	<dave.hansen@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>, Tejun Heo <tj@kernel.org>,
	Wu Fengguang <fengguang.wu@intel.com>
Subject: Re: [PATCH -v2] mm: Don't use radix tree writeback tags for pages in swap cache
Date: Wed, 31 Aug 2016 08:17:24 -0700	[thread overview]
Message-ID: <87oa49m0hn.fsf@yhuang-mobile.sh.intel.com> (raw)
In-Reply-To: <20160831091459.GY8119@techsingularity.net> (Mel Gorman's message of "Wed, 31 Aug 2016 10:14:59 +0100")

Mel Gorman <mgorman@techsingularity.net> writes:

> On Tue, Aug 30, 2016 at 10:28:09AM -0700, Huang, Ying wrote:
>> From: Huang Ying <ying.huang@intel.com>
>> 
>> File pages use a set of radix tree tags (DIRTY, TOWRITE, WRITEBACK,
>> etc.) to accelerate finding the pages with a specific tag in the radix
>> tree during inode writeback.  But for anonymous pages in the swap
>> cache, there is no inode writeback.  So there is no need to find the
>> pages with some writeback tags in the radix tree.  It is not necessary
>> to touch radix tree writeback tags for pages in the swap cache.
>> 
>> Per Rik van Riel's suggestion, a new flag AS_NO_WRITEBACK_TAGS is
>> introduced for address spaces which don't need to update the writeback
>> tags.  The flag is set for swap caches.  It may be used for DAX file
>> systems, etc.
>> 
>> With this patch, the swap out bandwidth improved 22.3% (from ~1.2GB/s to
>> ~ 1.48GBps) in the vm-scalability swap-w-seq test case with 8 processes.
>> The test is done on a Xeon E5 v3 system.  The swap device used is a RAM
>> simulated PMEM (persistent memory) device.  The improvement comes from
>> the reduced contention on the swap cache radix tree lock.  To test
>> sequential swapping out, the test case uses 8 processes, which
>> sequentially allocate and write to the anonymous pages until RAM and
>> part of the swap device is used up.
>> 
>> Details of comparison is as follow,
>> 
>> base             base+patch
>> ---------------- --------------------------
>>          %stddev     %change         %stddev
>>              \          |                \
>>    2506952 ±  2%     +28.1%    3212076 ±  7%  vm-scalability.throughput
>>    1207402 ±  7%     +22.3%    1476578 ±  6%  vmstat.swap.so
>>      10.86 ± 12%     -23.4%       8.31 ± 16%  perf-profile.cycles-pp._raw_spin_lock_irq.__add_to_swap_cache.add_to_swap_cache.add_to_swap.shrink_page_list
>>      10.82 ± 13%     -33.1%       7.24 ± 14%  perf-profile.cycles-pp._raw_spin_lock_irqsave.__remove_mapping.shrink_page_list.shrink_inactive_list.shrink_zone_memcg
>>      10.36 ± 11%    -100.0%       0.00 ± -1%  perf-profile.cycles-pp._raw_spin_lock_irqsave.__test_set_page_writeback.bdev_write_page.__swap_writepage.swap_writepage
>>      10.52 ± 12%    -100.0%       0.00 ± -1%  perf-profile.cycles-pp._raw_spin_lock_irqsave.test_clear_page_writeback.end_page_writeback.page_endio.pmem_rw_page
>> 
>
> I didn't see anything wrong with the patch but it's worth highlighting
> that this hunk means we are now out of GFP bits.

Sorry, I don't know whether I understand your words.  It is something
about,

__GFP_BITS_SHIFT == 26

So remainning bits in mapping_flags is 6.  And now the latest bit is
used for the flag introduced in the patch?

Best Regards,
Huang, Ying

>> diff --git a/include/linux/pagemap.h b/include/linux/pagemap.h
>> index 66a1260..2f5a65dd 100644
>> --- a/include/linux/pagemap.h
>> +++ b/include/linux/pagemap.h
>> @@ -25,6 +25,8 @@ enum mapping_flags {
>>  	AS_MM_ALL_LOCKS	= __GFP_BITS_SHIFT + 2,	/* under mm_take_all_locks() */
>>  	AS_UNEVICTABLE	= __GFP_BITS_SHIFT + 3,	/* e.g., ramdisk, SHM_LOCK */
>>  	AS_EXITING	= __GFP_BITS_SHIFT + 4, /* final truncate in progress */
>> +	/* writeback related tags are not used */
>> +	AS_NO_WRITEBACK_TAGS = __GFP_BITS_SHIFT + 5,
>>  };
>>  

WARNING: multiple messages have this Message-ID
From: "Huang\, Ying" <ying.huang@intel.com>
To: Mel Gorman <mgorman@techsingularity.net>
Cc: "Huang, Ying" <ying.huang@intel.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	tim.c.chen@intel.com, dave.hansen@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>, Tejun Heo <tj@kernel.org>,
	Wu Fengguang <fengguang.wu@intel.com>
Subject: Re: [PATCH -v2] mm: Don't use radix tree writeback tags for pages in swap cache
Date: Wed, 31 Aug 2016 08:17:24 -0700	[thread overview]
Message-ID: <87oa49m0hn.fsf@yhuang-mobile.sh.intel.com> (raw)
In-Reply-To: <20160831091459.GY8119@techsingularity.net> (Mel Gorman's message of "Wed, 31 Aug 2016 10:14:59 +0100")

Mel Gorman <mgorman@techsingularity.net> writes:

> On Tue, Aug 30, 2016 at 10:28:09AM -0700, Huang, Ying wrote:
>> From: Huang Ying <ying.huang@intel.com>
>> 
>> File pages use a set of radix tree tags (DIRTY, TOWRITE, WRITEBACK,
>> etc.) to accelerate finding the pages with a specific tag in the radix
>> tree during inode writeback.  But for anonymous pages in the swap
>> cache, there is no inode writeback.  So there is no need to find the
>> pages with some writeback tags in the radix tree.  It is not necessary
>> to touch radix tree writeback tags for pages in the swap cache.
>> 
>> Per Rik van Riel's suggestion, a new flag AS_NO_WRITEBACK_TAGS is
>> introduced for address spaces which don't need to update the writeback
>> tags.  The flag is set for swap caches.  It may be used for DAX file
>> systems, etc.
>> 
>> With this patch, the swap out bandwidth improved 22.3% (from ~1.2GB/s to
>> ~ 1.48GBps) in the vm-scalability swap-w-seq test case with 8 processes.
>> The test is done on a Xeon E5 v3 system.  The swap device used is a RAM
>> simulated PMEM (persistent memory) device.  The improvement comes from
>> the reduced contention on the swap cache radix tree lock.  To test
>> sequential swapping out, the test case uses 8 processes, which
>> sequentially allocate and write to the anonymous pages until RAM and
>> part of the swap device is used up.
>> 
>> Details of comparison is as follow,
>> 
>> base             base+patch
>> ---------------- --------------------------
>>          %stddev     %change         %stddev
>>              \          |                \
>>    2506952 A+-  2%     +28.1%    3212076 A+-  7%  vm-scalability.throughput
>>    1207402 A+-  7%     +22.3%    1476578 A+-  6%  vmstat.swap.so
>>      10.86 A+- 12%     -23.4%       8.31 A+- 16%  perf-profile.cycles-pp._raw_spin_lock_irq.__add_to_swap_cache.add_to_swap_cache.add_to_swap.shrink_page_list
>>      10.82 A+- 13%     -33.1%       7.24 A+- 14%  perf-profile.cycles-pp._raw_spin_lock_irqsave.__remove_mapping.shrink_page_list.shrink_inactive_list.shrink_zone_memcg
>>      10.36 A+- 11%    -100.0%       0.00 A+- -1%  perf-profile.cycles-pp._raw_spin_lock_irqsave.__test_set_page_writeback.bdev_write_page.__swap_writepage.swap_writepage
>>      10.52 A+- 12%    -100.0%       0.00 A+- -1%  perf-profile.cycles-pp._raw_spin_lock_irqsave.test_clear_page_writeback.end_page_writeback.page_endio.pmem_rw_page
>> 
>
> I didn't see anything wrong with the patch but it's worth highlighting
> that this hunk means we are now out of GFP bits.

Sorry, I don't know whether I understand your words.  It is something
about,

__GFP_BITS_SHIFT == 26

So remainning bits in mapping_flags is 6.  And now the latest bit is
used for the flag introduced in the patch?

Best Regards,
Huang, Ying

>> diff --git a/include/linux/pagemap.h b/include/linux/pagemap.h
>> index 66a1260..2f5a65dd 100644
>> --- a/include/linux/pagemap.h
>> +++ b/include/linux/pagemap.h
>> @@ -25,6 +25,8 @@ enum mapping_flags {
>>  	AS_MM_ALL_LOCKS	= __GFP_BITS_SHIFT + 2,	/* under mm_take_all_locks() */
>>  	AS_UNEVICTABLE	= __GFP_BITS_SHIFT + 3,	/* e.g., ramdisk, SHM_LOCK */
>>  	AS_EXITING	= __GFP_BITS_SHIFT + 4, /* final truncate in progress */
>> +	/* writeback related tags are not used */
>> +	AS_NO_WRITEBACK_TAGS = __GFP_BITS_SHIFT + 5,
>>  };
>>  

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

  reply	other threads:[~2016-08-31 15:17 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-30 17:28 Huang, Ying
2016-08-30 17:28 ` Huang, Ying
2016-08-30 18:29 ` Rik van Riel
2016-08-31  9:14 ` Mel Gorman
2016-08-31  9:14   ` Mel Gorman
2016-08-31 15:17   ` Huang, Ying [this message]
2016-08-31 15:17     ` Huang, Ying
2016-08-31 15:39     ` Mel Gorman
2016-08-31 15:39       ` Mel Gorman
2016-08-31 15:44       ` Huang, Ying
2016-08-31 15:44         ` Huang, Ying
2016-08-31 21:35       ` Andi Kleen
2016-08-31 21:35         ` Andi Kleen
2016-08-31 21:30   ` Andrew Morton
2016-08-31 21:30     ` Andrew Morton
2016-09-01  8:51     ` Mel Gorman
2016-09-01  8:51       ` Mel Gorman
2016-09-01  9:13     ` Michal Hocko
2016-09-01  9:13       ` Michal Hocko
2016-09-12 11:16       ` [PATCH 0/2] do not squash mapping flags and gfp_mask together (was: Re: [PATCH -v2] mm: Don't use radix tree writeback tags for pages in) Michal Hocko
2016-09-12 11:16         ` Michal Hocko
2016-09-12 11:16         ` [PATCH 1/2] fs: use mapping_set_error instead of opencoded set_bit Michal Hocko
2016-09-12 11:16           ` Michal Hocko
2016-09-12 22:11           ` Andrew Morton
2016-09-12 22:11             ` Andrew Morton
2016-09-12 22:18             ` Andrew Morton
2016-09-12 22:18               ` Andrew Morton
2016-09-13  6:53               ` Michal Hocko
2016-09-13  6:53                 ` Michal Hocko
2016-09-13 21:29                 ` Andrew Morton
2016-09-13 21:29                   ` Andrew Morton
2016-09-12 11:16         ` [PATCH 2/2] mm: split gfp_mask and mapping flags into separate fields Michal Hocko
2016-09-12 11:16           ` Michal Hocko
2016-09-12 11:48           ` Michal Hocko
2016-09-12 11:48             ` Michal Hocko

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=87oa49m0hn.fsf@yhuang-mobile.sh.intel.com \
    --to=ying.huang@intel.com \
    --cc=aaron.lu@intel.com \
    --cc=akpm@linux-foundation.org \
    --cc=andi.kleen@intel.com \
    --cc=dave.hansen@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 \
    --subject='Re: [PATCH -v2] mm: Don'\''t use radix tree writeback tags for pages in swap cache' \
    /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

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.