Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:3 as permitted sender) client-ip=2620:137:e000::3:3;
From:   "Huang, Ying" <ying.huang@intel.com>
To:     Mel Gorman <mgorman@techsingularity.net>
Cc:     <linux-mm@kvack.org>, <linux-kernel@vger.kernel.org>,
        Arjan Van De Ven <arjan@linux.intel.com>,
        Andrew Morton <akpm@linux-foundation.org>,
        Vlastimil Babka <vbabka@suse.cz>,
        David Hildenbrand <david@redhat.com>,
        Johannes Weiner <jweiner@redhat.com>,
        Dave Hansen <dave.hansen@linux.intel.com>,
        Michal Hocko <mhocko@suse.com>,
        Pavel Tatashin <pasha.tatashin@soleen.com>,
        Matthew Wilcox <willy@infradead.org>,
        "Christoph Lameter" <cl@linux.com>
Subject: Re: [PATCH 09/10] mm, pcp: avoid to reduce PCP high unnecessarily
References: <20230920061856.257597-1-ying.huang@intel.com>
        <20230920061856.257597-10-ying.huang@intel.com>
        <20231011140949.rwsqfb57vyuub6va@techsingularity.net>
        <87lec8ffij.fsf@yhuang6-desk2.ccr.corp.intel.com>
        <20231012124958.dj5ug5hih3joa542@techsingularity.net>
Date:   Thu, 12 Oct 2023 21:19:03 +0800
In-Reply-To: <20231012124958.dj5ug5hih3joa542@techsingularity.net> (Mel
        Gorman's message of "Thu, 12 Oct 2023 13:49:58 +0100")
Message-ID: <87r0m0dlmg.fsf@yhuang6-desk2.ccr.corp.intel.com>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=ascii
Precedence: bulk

Mel Gorman <mgorman@techsingularity.net> writes:

> On Thu, Oct 12, 2023 at 03:48:04PM +0800, Huang, Ying wrote:
>> "
>> On a 2-socket Intel server with 224 logical CPU, we run 8 kbuild
>> instances in parallel (each with `make -j 28`) in 8 cgroup.  This
>> simulates the kbuild server that is used by 0-Day kbuild service.
>> With the patch, The number of pages allocated from zone (instead of
>> from PCP) decreases 21.4%.
>> "
>> 
>> I also showed the performance number for each step of optimization as
>> follows (copied from the above patchset V2 link).
>> 
>> "
>> 	build time   lock contend%	free_high	alloc_zone
>> 	----------	----------	---------	----------
>> base	     100.0	      13.5          100.0            100.0
>> patch1	      99.2	      10.6	     19.2	      95.6
>> patch3	      99.2	      11.7	      7.1	      95.6
>> patch5	      98.4	      10.0	      8.2	      97.1
>> patch7	      94.9	       0.7	      3.0	      19.0
>> patch9	      94.9	       0.6	      2.7	      15.0  <--	this patch
>> patch10	      94.9	       0.9	      8.8	      18.6
>> "
>> 
>> Although I think the patch is helpful via avoiding the unnecessary
>> pcp->high decaying, thus reducing the zone lock contention.  There's no
>> visible benchmark score change for the patch.
>> 
>
> Thanks!
>
> Given that it's another PCP field with an update in a relatively hot
> path, I would suggest dropping this patch entirely if it does not affect
> performance. It has the risk of being a magical heuristic that we forget
> later whether it's even worthwhile.

OK.  Hope we can find some workloads that can benefit from the patch in
the future.

--
Best Regards,
Huang, Ying