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 (diff)
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>
next prev parent 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 [PATCH -v2] mm: Don't use radix tree writeback tags for pages in swap cache 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 \ /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: linkBe 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.