Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp3550574pxj; Mon, 24 May 2021 09:10:28 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyMXLM1iGo4NDsB9DNjhhVOIlNkbOOEpxOaxXOi6BM5j0aqdwi04hcHlEtvWZ1WSXcd6272 X-Received: by 2002:a92:2a09:: with SMTP id r9mr17005355ile.300.1621872628006; Mon, 24 May 2021 09:10:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1621872627; cv=none; d=google.com; s=arc-20160816; b=eWSy013YUdWABBWu+qBHHPsjot5R31Z5YWJntJPVW682VweItrx/kCMMS2KbYbVeaS HXeMxZP+57YPwOzYWsOfgQKqFAmsCRy7gpFtQAcRoCKrsH71sMMhjCyNGwDPHOpdXyyn GRA4UMo0Ab2lMUbjaDmHosou++jpD6PQKnGHitx0B1Ba8+zOgtsbU1Oy8wlh2gqCHCqr 7qxazG2rgYc66ihxNfKRHBNQPs9/oczMp7GQ5oJz+VxZF5dGFxOhCwdFS5cCKTJ3kGWx KH2+0pPpRqHUMi+f6+sFKdWBQVlCDg7GLOGPhwSKVnu/2vkPQYnTMaHVEltPlb+qo1ZY x3Fg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=gngd4zFdZLlNC/lRQCT2jLn27iyoqhRfiCfeCU81Sgs=; b=sFw8wAjnrOJIbCoRb/5iXtM0Sb3tQi49n7lTlqcsmoD9gr33tzOvi5qURTK2+KxKqi 6Sal68CoOmg48hP7Ku8bh0iosXzD6xGqI4vUqVft7GhplIiC+23k6cPPsD0ChOajGsLk PCQaSMAL/1iQC7NdK29ekQoIqGiiGnb8IAJ8dcbKP81etfIDaogP5HvCUVMBANI882K1 wsz9CCKRGJvBF938qYTBGa3Or7fsi0JH/PFYfAX7Lv2IH+6iffCrhP6W6Oe8kFeNdIAA wHJLd5XgOH9xVLrhn9hQUTVTxJUeCCYlZi12DOiFROsoR5iSbyLyRc3M4q/BMFz+WuyS QYag== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id b1si14733358ioh.94.2021.05.24.09.10.13; Mon, 24 May 2021 09:10:27 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235413AbhEXQKl (ORCPT + 99 others); Mon, 24 May 2021 12:10:41 -0400 Received: from outbound-smtp02.blacknight.com ([81.17.249.8]:55614 "EHLO outbound-smtp02.blacknight.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233704AbhEXQCd (ORCPT ); Mon, 24 May 2021 12:02:33 -0400 Received: from mail.blacknight.com (pemlinmail06.blacknight.ie [81.17.255.152]) by outbound-smtp02.blacknight.com (Postfix) with ESMTPS id 068C3BAA92 for ; Mon, 24 May 2021 17:01:03 +0100 (IST) Received: (qmail 432 invoked from network); 24 May 2021 16:01:02 -0000 Received: from unknown (HELO techsingularity.net) (mgorman@techsingularity.net@[84.203.23.168]) by 81.17.254.9 with ESMTPSA (AES256-SHA encrypted, authenticated); 24 May 2021 16:01:02 -0000 Date: Mon, 24 May 2021 17:01:01 +0100 From: Mel Gorman To: Dave Hansen Cc: Linux-MM , Dave Hansen , Matthew Wilcox , Vlastimil Babka , Michal Hocko , Nicholas Piggin , LKML Subject: Re: [PATCH 3/6] mm/page_alloc: Adjust pcp->high after CPU hotplug events Message-ID: <20210524160101.GG30378@techsingularity.net> References: <20210521102826.28552-1-mgorman@techsingularity.net> <20210521102826.28552-4-mgorman@techsingularity.net> <20210524090726.GB30378@techsingularity.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, May 24, 2021 at 08:52:02AM -0700, Dave Hansen wrote: > > To address your point requires much deeper surgery. > ... > > There is value to doing something like this but it's beyond what this > > series is trying to do and doing the work without introducing regressions > > would be very difficult. > > Agreed, such a solution is outside of the scope of what this set is > trying to do. > > It would be nice to touch on this counter-intuitive property in the > changelog, and *maybe* add a WARN_ON_ONCE() if we hit an edge case. > Maybe WARN_ON_ONCE() if pcp->high gets below pcp->batch*SOMETHING. > I think it's reasonable to ensure pcp->batch is never above pcp->high so I have this in zone_highsize now + /* + * Ensure high is at least batch*4. The multiple is based on the + * historical relationship between high and batch. + */ + high = max(high, batch << 2); Performance tests are running and I'll post a v2 assuming they pass. -- Mel Gorman SUSE Labs