Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19;
Date:   Thu, 5 May 2022 16:27:04 +0800
From:   Aaron Lu <aaron.lu@intel.com>
To:     Mel Gorman <mgorman@techsingularity.net>
CC:     kernel test robot <oliver.sang@intel.com>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        Vlastimil Babka <vbabka@suse.cz>,
        "Dave Hansen" <dave.hansen@linux.intel.com>,
        Jesper Dangaard Brouer <brouer@redhat.com>,
        Michal Hocko <mhocko@kernel.org>,
        Andrew Morton <akpm@linux-foundation.org>,
        LKML <linux-kernel@vger.kernel.org>, <lkp@lists.01.org>,
        <lkp@intel.com>, <ying.huang@intel.com>, <feng.tang@intel.com>,
        <zhengjun.xing@linux.intel.com>, <fengwei.yin@intel.com>
Subject: Re: [mm/page_alloc]  f26b3fa046:  netperf.Throughput_Mbps -18.0%
 regression
Message-ID: <YnOKWNE3PZzzohNH@ziqianlu-desk1>
References: <20220420013526.GB14333@xsang-OptiPlex-9020>
 <YmvMDyx05UoPFtQy@ziqianlu-desk1>
 <20220429133918.GC3441@techsingularity.net>
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <20220429133918.GC3441@techsingularity.net>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?uLA+rz0Vypy7Dv2gYh1s9BvBY3/yd5DtGEx3w9nWpeoEsK467peMUxplyPaY?=
 =?us-ascii?Q?g9VrcEv069zI6wafjPHcOamaT8mEf9fHQ+DzLvxKFABMQD7k/WQTfCK20Inq?=
 =?us-ascii?Q?styhdHrE54/GwwIB5HLlshEDm6kQDFn2hIC3M0qIZnNAsmF80fzdH3OpqyEf?=
 =?us-ascii?Q?IdMOMKx3jYk8a1L6D+DBDM47Dgsx5AMXAt2NGh+GWdXW/uyITAZcuNpAxlIV?=
 =?us-ascii?Q?q2lLWB6TJHzSLYKF9rtkFU8XPNZitsFza7IAtL0tZnOMKa27rAIvVwbJIsHF?=
 =?us-ascii?Q?dq2povKZX0veaTjXDHotliLYvffKwzppinln/shRGB5i7bFK2YO5aDHUvLzf?=
 =?us-ascii?Q?Z668jsQuroSkqv7Et8z2n4B3PUGqhEVnksu9bIE2uwhKbQSFrADAw1JDKQzp?=
 =?us-ascii?Q?6zCIPapzY7W59QEZVozE4lBe7uhqQ7hAbJGXdEqY8Jnm+qQrO2vfxgi6MC6E?=
 =?us-ascii?Q?Hs7Te3xPly4+ZlwKp37jUG7lO7utOU0s9nkAKoLD1oLn0jcAW3pRpIGBkeqY?=
 =?us-ascii?Q?cJvnVPgx3v/eNKMZQKHLcquwfkLf9GTx1PDMO7QpIzhpoIcjEu25UV5DXZwW?=
 =?us-ascii?Q?ftUXlh1avWdzmKLOyT4eRdNy6VY0Ybp1sTUFVmhZh2VpGCj5Tcg5lQm6jpAw?=
 =?us-ascii?Q?kIPKTtpbg/MCmcM/v9kj9cQYF9vV1FFwhyPGDXu1EZjZHTyc6IRVlzNi+XKe?=
 =?us-ascii?Q?A1X4kt7nZoCqpdeFNssTm600ZcN0//1H9eVksXZAbiM4vYCpwRhY73D8fMxt?=
 =?us-ascii?Q?NFXKKOnLeMEvubTwgXANcZreoFg8sAaH69WWhQt7bzqkmWlqkWk7Se9/mJW7?=
 =?us-ascii?Q?kwFw7+hhe5kZ18tECjyVnobtdB0tLDIlZ14yjtEDtlOqiugwxNvaS1O7kbzu?=
 =?us-ascii?Q?AJWU1MRBIzAqn08/COqw0aAeIeV5PAieSuC4QfxGvXsgM9XXPkiCzIHWFy31?=
 =?us-ascii?Q?hjjE/ZNXMLb0XwfYmgf8mr93CcwrHUC1Rxa0i1F+rRhimCFBhcKwgXXLmEab?=
 =?us-ascii?Q?PSyTdHflVm6Qjek1ySDOfI/pEUr1ft36KAmR6+luO0Wj/j/BMYBd8ic0bvlr?=
 =?us-ascii?Q?fzHBzLt16LyBAYlWZ4JTyDJTmioaiZLR4/kNpX3SY46jKU0v5uEHekXAdsG/?=
 =?us-ascii?Q?HgkIUyTGKCPzVRMEFuORC4d1dsr7F8B6kCIAQ4VMkWDeOFTZcwe4dl9FT7WA?=
 =?us-ascii?Q?xOCB4T7IQ0rJ9h8e6YGRx4ThdysmspetaYexOMybV8z0UN5+FEvV39e9z0UE?=
 =?us-ascii?Q?suxqQSVQTChs+ryuh3xyLGaSMSOGPM//Llpau8G1ur7IJkMLbDdf996q/fuN?=
 =?us-ascii?Q?UP6aMp21JtrQbIDcsTZNcBfH0yGpsS+/FCekAn/zWwKKHTRqy2JINiXGZYEv?=
 =?us-ascii?Q?l/EFsYUv2k3vZLpX5OSyitX5uaqgVbpnZRLB5o9SXeDzuIo+vRtZRK5MffZd?=
 =?us-ascii?Q?jBcGVq0nxy2aok5XMKGDSNU1T0/+9/r+Gr1aqPuwNfsIDM6zVkcE9m09J3lx?=
 =?us-ascii?Q?FIaZZmOgZcksPkOggpNymZeZ50NoS3ZtF4ro5ujeC7WoMiZ/Dg2EJkQEZBJw?=
 =?us-ascii?Q?23DhukbbY92mS/FV160GOMZhpUYebESk/M28GZRqoN6BndScXmnHh6RbL+AU?=
 =?us-ascii?Q?XlCYEGjsMiJ0tbRzdNVlxfy4P+EQ6K0GJWqsVfs4EuhR1UrWBY4bMq4idvAX?=
 =?us-ascii?Q?hAmp2aZ4DlrVvMRXS3UEaYuwk2DaFMUQdmPquDavmZGvWbwJnfECXrgnM5SP?=
 =?us-ascii?Q?wnWfdWtouw=3D=3D?=
X-MS-Exchange-CrossTenant-Network-Message-Id: 75b2f102-f241-4f4c-ece6-08da2e711094
X-MS-Exchange-CrossTenant-AuthSource: BYAPR11MB3062.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 May 2022 08:27:17.2130
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: pUOfJs/LozO7qbJovusPwqm06WTG7V30aw1LPoonMxseOkFd7MmKO1cckJOU0K1rHAj2JFPOs8IWY5ZDlYFjZg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR11MB4345
X-OriginatorOrg: intel.com
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,
	DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,
	MAILING_LIST_MULTI,RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE
	autolearn=unavailable autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
	lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Fri, Apr 29, 2022 at 02:39:18PM +0100, Mel Gorman wrote:
> On Fri, Apr 29, 2022 at 07:29:19PM +0800, Aaron Lu wrote:

... ...

> > The said change looks like this:
> > (relevant comment will have to be adjusted)
> > 
> > diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> > index 505d59f7d4fa..130a02af8321 100644
> > --- a/mm/page_alloc.c
> > +++ b/mm/page_alloc.c
> > @@ -3332,18 +3332,19 @@ static int nr_pcp_high(struct per_cpu_pages *pcp, struct zone *zone,
> >  		       bool free_high)
> >  {
> >  	int high = READ_ONCE(pcp->high);
> > +	int batch = READ_ONCE(pcp->batch);
> >  
> > -	if (unlikely(!high || free_high))
> > +	if (unlikely(!high))
> >  		return 0;
> >  
> > -	if (!test_bit(ZONE_RECLAIM_ACTIVE, &zone->flags))
> > -		return high;
> > -
> >  	/*
> >  	 * If reclaim is active, limit the number of pages that can be
> >  	 * stored on pcp lists
> >  	 */
> > -	return min(READ_ONCE(pcp->batch) << 2, high);
> > +	if (test_bit(ZONE_RECLAIM_ACTIVE, &zone->flags) || free_high)
> > +		return min(batch << 2, high);
> > +
> > +	return high;
> >  }
> >  
> >  static void free_unref_page_commit(struct page *page, int migratetype,
> > 
> > Does this look sane? If so, I can prepare a formal patch with proper
> > comment and changelog, thanks.
> 
> I think it looks reasonable sane. The corner case is that if
> ((high - (batch >> 2)) > cachesize) that the pages will not get recycled

When free_high is true, the above diff changed the return value of
nr_pcp_high() from 0 to min(batch << 2, pcp->high) so the corner case is
when (min(batch << 2, pcp->high) > cachesize)?

> quickly enough. On the plus side always freeing to buddy may contend on the
> zone lock again and freeing in batches reduces that risk.
> 
> Given that zone lock contention is reduced regardless of cache size, it
> seems like a reasonable tradeoff.

Glad to hear this.