Received: by 2002:a05:7412:f690:b0:e2:908c:2ebd with SMTP id ej16csp314399rdb; Thu, 19 Oct 2023 05:33:46 -0700 (PDT) X-Google-Smtp-Source: AGHT+IGPym8odFyStUppbaAOB7lL4RA5bOifpkl3MU4UiSsps5MZPuU9F9TlIahllv6y3qKrV9gb X-Received: by 2002:a05:6870:1351:b0:1d6:5c40:11b6 with SMTP id 17-20020a056870135100b001d65c4011b6mr2415100oac.14.1697718826704; Thu, 19 Oct 2023 05:33:46 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1697718826; cv=none; d=google.com; s=arc-20160816; b=p5iBu0C6OvfBdZi3+Q7VxWKOHPmfkl0BPhha39ienxur8/WdnhjYFIBn4VVgVOv628 ot405NZ2TlE8tyy7nGeMsVyfQzw3rMb+weFDeHfyXAoHVF7UPCHVe4srGK4oB8YRafuv mrFqgRnhG2lAwAIVpex7wnSMPop5AsIo0OAd1iub8aVOVyyCgtYB3paLxpG03Kj+Nr62 CjZnkjIAUVOvjvdfpREZ3V3YKF0csDp5PkILgG5bRj3RFYLHZFXW2IYIPgmHnVbrIZ9W 1crIFrbEfBAVaGeeF5eelINpALD9Owg8Cx/Ii4nTbN/wJX24zp+YY2LPTZ0+fQuSjd5O Lpkw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=3k73M0izFQKjRiex5t/rRS+uZFJCZ2vQlMjKArTUbvs=; fh=HR4DBHbif49FM8LxiYZcqJ7T0XBSkbhO9SOtYE6LAJA=; b=mOKk9zekaYLOrxR9hy8Avy7WZy5GHgmYz/wI1jQkGbaPA1ntWs0S8R7uUmMs9/Buvn NTumIW/qYox1MwRxbYKq8reQFWvz5tPqJbCnEuMXcVqheJ0qm6oYTN/G0WGBJ3GYBSEM XyQqNZ0NOdMwI4GvtWa2apUZ3OoVtGP711igGuW6ft/D94Op9ws06jmyjHMXbjpmZV3h ToJNjStje0R8yn7M9Fcmor2UbNepZsNenPJVoq7SznERPO8KT2YXZZ66g/8B3aUp9yDw A2rFb0pgIzAnTpYppNn6dp8/yyHTXli4RJLRrZCzRrgVSXm3pyNC6rT0WKC99CA8M9oT fUFA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:4 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from howler.vger.email (howler.vger.email. [2620:137:e000::3:4]) by mx.google.com with ESMTPS id bf13-20020a656d0d000000b00574166b7d34si4127133pgb.881.2023.10.19.05.33.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 19 Oct 2023 05:33:46 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:4 as permitted sender) client-ip=2620:137:e000::3:4; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:4 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by howler.vger.email (Postfix) with ESMTP id 29BB1827AFA2; Thu, 19 Oct 2023 05:33:44 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at howler.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1345598AbjJSMdV (ORCPT + 99 others); Thu, 19 Oct 2023 08:33:21 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45852 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1345439AbjJSMdQ (ORCPT ); Thu, 19 Oct 2023 08:33:16 -0400 Received: from outbound-smtp24.blacknight.com (outbound-smtp24.blacknight.com [81.17.249.192]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 101329B for ; Thu, 19 Oct 2023 05:33:13 -0700 (PDT) Received: from mail.blacknight.com (pemlinmail04.blacknight.ie [81.17.254.17]) by outbound-smtp24.blacknight.com (Postfix) with ESMTPS id 6484CC0DAA for ; Thu, 19 Oct 2023 13:33:12 +0100 (IST) Received: (qmail 23318 invoked from network); 19 Oct 2023 12:33:12 -0000 Received: from unknown (HELO techsingularity.net) (mgorman@techsingularity.net@[84.203.199.31]) by 81.17.254.9 with ESMTPSA (AES256-SHA encrypted, authenticated); 19 Oct 2023 12:33:12 -0000 Date: Thu, 19 Oct 2023 13:33:10 +0100 From: Mel Gorman To: Huang Ying Cc: Andrew Morton , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Arjan Van De Ven , Vlastimil Babka , David Hildenbrand , Johannes Weiner , Dave Hansen , Michal Hocko , Pavel Tatashin , Matthew Wilcox , Christoph Lameter Subject: Re: [PATCH -V3 8/9] mm, pcp: decrease PCP high if free pages < high watermark Message-ID: <20231019123310.pirier6sk6iaqr3n@techsingularity.net> References: <20231016053002.756205-1-ying.huang@intel.com> <20231016053002.756205-9-ying.huang@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: <20231016053002.756205-9-ying.huang@intel.com> X-Spam-Status: No, score=-0.8 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on howler.vger.email Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (howler.vger.email [0.0.0.0]); Thu, 19 Oct 2023 05:33:44 -0700 (PDT) On Mon, Oct 16, 2023 at 01:30:01PM +0800, Huang Ying wrote: > One target of PCP is to minimize pages in PCP if the system free pages > is too few. To reach that target, when page reclaiming is active for > the zone (ZONE_RECLAIM_ACTIVE), we will stop increasing PCP high in > allocating path, decrease PCP high and free some pages in freeing > path. But this may be too late because the background page reclaiming > may introduce latency for some workloads. So, in this patch, during > page allocation we will detect whether the number of free pages of the > zone is below high watermark. If so, we will stop increasing PCP high > in allocating path, decrease PCP high and free some pages in freeing > path. With this, we can reduce the possibility of the premature > background page reclaiming caused by too large PCP. > > The high watermark checking is done in allocating path to reduce the > overhead in hotter freeing path. > > Signed-off-by: "Huang, Ying" > Cc: Andrew Morton > Cc: Mel Gorman > Cc: Vlastimil Babka > Cc: David Hildenbrand > Cc: Johannes Weiner > Cc: Dave Hansen > Cc: Michal Hocko > Cc: Pavel Tatashin > Cc: Matthew Wilcox > Cc: Christoph Lameter > --- > include/linux/mmzone.h | 1 + > mm/page_alloc.c | 33 +++++++++++++++++++++++++++++++-- > 2 files changed, 32 insertions(+), 2 deletions(-) > > diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h > index ec3f7daedcc7..c88770381aaf 100644 > --- a/include/linux/mmzone.h > +++ b/include/linux/mmzone.h > @@ -1018,6 +1018,7 @@ enum zone_flags { > * Cleared when kswapd is woken. > */ > ZONE_RECLAIM_ACTIVE, /* kswapd may be scanning the zone. */ > + ZONE_BELOW_HIGH, /* zone is below high watermark. */ > }; > > static inline unsigned long zone_managed_pages(struct zone *zone) > diff --git a/mm/page_alloc.c b/mm/page_alloc.c > index 8382ad2cdfd4..253fc7d0498e 100644 > --- a/mm/page_alloc.c > +++ b/mm/page_alloc.c > @@ -2407,7 +2407,13 @@ static int nr_pcp_high(struct per_cpu_pages *pcp, struct zone *zone, > return min(batch << 2, pcp->high); > } > > - if (pcp->count >= high && high_min != high_max) { > + if (high_min == high_max) > + return high; > + > + if (test_bit(ZONE_BELOW_HIGH, &zone->flags)) { > + pcp->high = max(high - (batch << pcp->free_factor), high_min); > + high = max(pcp->count, high_min); > + } else if (pcp->count >= high) { > int need_high = (batch << pcp->free_factor) + batch; > > /* pcp->high should be large enough to hold batch freed pages */ > @@ -2457,6 +2463,10 @@ static void free_unref_page_commit(struct zone *zone, struct per_cpu_pages *pcp, > if (pcp->count >= high) { > free_pcppages_bulk(zone, nr_pcp_free(pcp, batch, high, free_high), > pcp, pindex); > + if (test_bit(ZONE_BELOW_HIGH, &zone->flags) && > + zone_watermark_ok(zone, 0, high_wmark_pages(zone), > + ZONE_MOVABLE, 0)) > + clear_bit(ZONE_BELOW_HIGH, &zone->flags); > } > } > This is a relatively fast path and freeing pages should not need to check watermarks. While the overhead is mitigated because it applies only when the watermark is below high, that is also potentially an unbounded condition if a workload is sized precisely enough. Why not clear this bit when kswapd is going to sleep after reclaiming enough pages in a zone? If you agree then a follow-up patch classed as a micro-optimisation is sufficient to avoid redoing all the results again. For most of your tests, it should be performance-neutral or borderline noise. -- Mel Gorman SUSE Labs