From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.3 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4D289CA9EA1 for ; Fri, 18 Oct 2019 12:54:55 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id E7C09222C2 for ; Fri, 18 Oct 2019 12:54:54 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E7C09222C2 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=techsingularity.net Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 94CD28E0006; Fri, 18 Oct 2019 08:54:54 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 8FBA78E0003; Fri, 18 Oct 2019 08:54:54 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8126A8E0006; Fri, 18 Oct 2019 08:54:54 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0098.hostedemail.com [216.40.44.98]) by kanga.kvack.org (Postfix) with ESMTP id 5F1D48E0003 for ; Fri, 18 Oct 2019 08:54:54 -0400 (EDT) Received: from smtpin26.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with SMTP id ED6C682F7A90 for ; Fri, 18 Oct 2019 12:54:53 +0000 (UTC) X-FDA: 76056900066.26.birds23_2ab031a4f215b X-HE-Tag: birds23_2ab031a4f215b X-Filterd-Recvd-Size: 2841 Received: from outbound-smtp37.blacknight.com (outbound-smtp37.blacknight.com [46.22.139.220]) by imf39.hostedemail.com (Postfix) with ESMTP for ; Fri, 18 Oct 2019 12:54:53 +0000 (UTC) Received: from mail.blacknight.com (unknown [81.17.254.16]) by outbound-smtp37.blacknight.com (Postfix) with ESMTPS id 47CFD197C for ; Fri, 18 Oct 2019 13:54:51 +0100 (IST) Received: (qmail 7074 invoked from network); 18 Oct 2019 12:54:51 -0000 Received: from unknown (HELO techsingularity.net) (mgorman@techsingularity.net@[84.203.19.210]) by 81.17.254.9 with ESMTPSA (AES256-SHA encrypted, authenticated); 18 Oct 2019 12:54:51 -0000 Date: Fri, 18 Oct 2019 13:54:49 +0100 From: Mel Gorman To: Matt Fleming Cc: Andrew Morton , Michal Hocko , Vlastimil Babka , Thomas Gleixner , Borislav Petkov , Linux-MM , Linux Kernel Mailing List Subject: Re: [PATCH 0/3] Recalculate per-cpu page allocator batch and high limits after deferred meminit Message-ID: <20191018125449.GJ3321@techsingularity.net> References: <20191018105606.3249-1-mgorman@techsingularity.net> <20191018115849.GH4065@codeblueprint.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: <20191018115849.GH4065@codeblueprint.co.uk> User-Agent: Mutt/1.10.1 (2018-07-13) X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Fri, Oct 18, 2019 at 12:58:49PM +0100, Matt Fleming wrote: > On Fri, 18 Oct, at 11:56:03AM, Mel Gorman wrote: > > A private report stated that system CPU usage was excessive on an AMD > > EPYC 2 machine while building kernels with much longer build times than > > expected. The issue is partially explained by high zone lock contention > > due to the per-cpu page allocator batch and high limits being calculated > > incorrectly. This series addresses a large chunk of the problem. Patch 1 > > is mostly cosmetic but prepares for patch 2 which is the real fix. Patch > > 3 is definiely cosmetic but was noticed while implementing the fix. Proper > > details are in the changelog for patch 2. > > > > include/linux/mm.h | 3 --- > > mm/internal.h | 3 +++ > > mm/page_alloc.c | 33 ++++++++++++++++++++------------- > > 3 files changed, 23 insertions(+), 16 deletions(-) > > Just to confirm, these patches don't fix the issue we're seeing on the > EPYC 2 machines, but they do return the batch sizes to sensible values. To be clear, does the patch a) fix *some* of the issue and there is something else also going on that needs to be chased down or b) has no impact on build time or system CPU usage on your machine? -- Mel Gorman SUSE Labs