From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933338AbcFGV4q (ORCPT ); Tue, 7 Jun 2016 17:56:46 -0400 Received: from gum.cmpxchg.org ([85.214.110.215]:58460 "EHLO gum.cmpxchg.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933273AbcFGV4p (ORCPT ); Tue, 7 Jun 2016 17:56:45 -0400 Date: Tue, 7 Jun 2016 17:56:27 -0400 From: Johannes Weiner To: Ye Xiaolong Cc: Rik van Riel , lkp@01.org, LKML , Mel Gorman , David Rientjes , Joonsoo Kim , Linus Torvalds , Andrew Morton Subject: Re: [LKP] [lkp] [mm] 795ae7a0de: pixz.throughput -9.1% regression Message-ID: <20160607215627.GA13614@cmpxchg.org> References: <574fd097.Frf8OIpckXVh1oaw%xiaolong.ye@intel.com> <20160602064507.GE30850@yexl-desktop> <20160602160706.GA24004@cmpxchg.org> <20160603222109.GA12579@cmpxchg.org> <20160606085307.GB2926@yexl-desktop> <20160607044817.GC16057@yexl-desktop> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20160607044817.GC16057@yexl-desktop> User-Agent: Mutt/1.6.1 (2016-04-27) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jun 07, 2016 at 12:48:17PM +0800, Ye Xiaolong wrote: > FYI, below is the comparison info between 3ed3a4f, 795ae7ay, v4.7-rc2 and the > revert commit (eaa7f0d). Thanks for running this. Alas, I still can not make heads or tails of this, or reproduce it locally for that matter. With this test run, there seems to be a significant increase in system time: > 92.03 ± 0% +5.6% 97.23 ± 11% +30.5% 120.08 ± 1% +30.0% 119.61 ± 0% pixz.time.system_time Would it be possible to profile the testruns using perf? Maybe we can find out where the kernel is spending the extra time. But just to make sure I'm looking at the right code, can you first try the following patch on top of Linus's current tree and see if that gets performance back to normal? It's a partial revert of the watermarks that singles out the fair zone allocator: >>From 2015eaad688486d65fcf86185e213fff8506b3fe Mon Sep 17 00:00:00 2001 From: Johannes Weiner Date: Tue, 7 Jun 2016 17:45:03 -0400 Subject: [PATCH] mm: revert fairness batching to before the watermarks were boosted Signed-off-by: Johannes Weiner --- include/linux/mmzone.h | 2 ++ mm/page_alloc.c | 6 ++++-- 2 files changed, 6 insertions(+), 2 deletions(-) diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h index 02069c2..4565b92 100644 --- a/include/linux/mmzone.h +++ b/include/linux/mmzone.h @@ -327,6 +327,8 @@ struct zone { /* zone watermarks, access with *_wmark_pages(zone) macros */ unsigned long watermark[NR_WMARK]; + unsigned long fairbatch; + unsigned long nr_reserved_highatomic; /* diff --git a/mm/page_alloc.c b/mm/page_alloc.c index 6903b69..33387ab 100644 --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -2889,7 +2889,7 @@ static void reset_alloc_batches(struct zone *preferred_zone) do { mod_zone_page_state(zone, NR_ALLOC_BATCH, - high_wmark_pages(zone) - low_wmark_pages(zone) - + zone->fairbatch - atomic_long_read(&zone->vm_stat[NR_ALLOC_BATCH])); clear_bit(ZONE_FAIR_DEPLETED, &zone->flags); } while (zone++ != preferred_zone); @@ -6842,6 +6842,8 @@ static void __setup_per_zone_wmarks(void) zone->watermark[WMARK_MIN] = tmp; } + zone->fairbatch = tmp >> 2; + /* * Set the kswapd watermarks distance according to the * scale factor in proportion to available memory, but @@ -6855,7 +6857,7 @@ static void __setup_per_zone_wmarks(void) zone->watermark[WMARK_HIGH] = min_wmark_pages(zone) + tmp * 2; __mod_zone_page_state(zone, NR_ALLOC_BATCH, - high_wmark_pages(zone) - low_wmark_pages(zone) - + zone->fairbatch - atomic_long_read(&zone->vm_stat[NR_ALLOC_BATCH])); spin_unlock_irqrestore(&zone->lock, flags); -- 2.8.2