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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id F2285CDB46E for ; Thu, 12 Oct 2023 12:21:38 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 73EAA8D0010; Thu, 12 Oct 2023 08:21:38 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6ED8E8D0002; Thu, 12 Oct 2023 08:21:38 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5DD088D0010; Thu, 12 Oct 2023 08:21:38 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 4CF068D0002 for ; Thu, 12 Oct 2023 08:21:38 -0400 (EDT) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 264751205DD for ; Thu, 12 Oct 2023 12:21:38 +0000 (UTC) X-FDA: 81336720276.04.4109279 Received: from mgamail.intel.com (mgamail.intel.com [192.55.52.88]) by imf11.hostedemail.com (Postfix) with ESMTP id D67A740022 for ; Thu, 12 Oct 2023 12:21:35 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=YTJaBtOb; spf=pass (imf11.hostedemail.com: domain of ying.huang@intel.com designates 192.55.52.88 as permitted sender) smtp.mailfrom=ying.huang@intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1697113296; a=rsa-sha256; cv=none; b=sQxaxyGxAc3GC3zGkFdHfJiTn2ng97QV1oUVeI9nW90Cax0nMnuDY6cNZFBXbCXUdRbQNc +uZsz3gRv5anNIlUMuvNdmjR5gxjcmXvWcMm/9D7DqpvtTdAdZ3qoN6RSAaS1QgzFCJWVu BfeyhnmhEJILWkYvd+XMVcLd7lZvP38= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=YTJaBtOb; spf=pass (imf11.hostedemail.com: domain of ying.huang@intel.com designates 192.55.52.88 as permitted sender) smtp.mailfrom=ying.huang@intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1697113296; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=ieIv2kcPmzeM0AuLi2yzDJS846P0rCclvFcU3uZ++lE=; b=6cd5EC0EBNOFTgEtmGLos1POO5MQGQiLUoyCjiEPLgWrK4eIAq2InM+sg+lDNVW5WHhMKd VPvzFraMRc9CcMS43XyJxKWjYRGa3EF5QR2Nx/VUDU9/at9LLVBPKZ2Fd8yX5gQsz6qqc/ XMnDNkurzrJ2+5UWf00nN2G4utGsTU0= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1697113295; x=1728649295; h=from:to:cc:subject:references:date:in-reply-to: message-id:mime-version; bh=ixkSmhc0z6SM+bfRBeoO6e2JQoDTNcHFRF+Mw8JUm40=; b=YTJaBtObeesTkoXivFwBwlOI4O1HLHHRgiY9mHSs3G/mF3aEG6OF6ZZ2 kuetFWkqVzQQ6aOs1WgiDdvfEQXezjJS5vOTVkkpnzkHt1dr3vhClB+E4 9PVc9HuJKdckzBHFtw3KE5yu/Z9F983B2eVgB/hR7hBBTJRMcWkJv/l+8 iL+J9ZVJzuOBC60v0j0DlOPlNPc2mnE1I3Ki7CWFZjfH9cnE1npQoE9hN uiTF48TWIuXpJkziAUihGCApkI8bote1pAQVnC9LbzckbpllIxPKQZLl5 SkOGnWW2B6+9Em82rIDjcUqbpWtuLFRNuSC5s4K4wkKK1W3fiTPhbvzqa Q==; X-IronPort-AV: E=McAfee;i="6600,9927,10861"; a="415953513" X-IronPort-AV: E=Sophos;i="6.03,218,1694761200"; d="scan'208";a="415953513" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by fmsmga101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 12 Oct 2023 05:21:34 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10861"; a="783681885" X-IronPort-AV: E=Sophos;i="6.03,218,1694761200"; d="scan'208";a="783681885" Received: from yhuang6-desk2.sh.intel.com (HELO yhuang6-desk2.ccr.corp.intel.com) ([10.238.208.55]) by orsmga008-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 12 Oct 2023 05:21:30 -0700 From: "Huang, Ying" To: Mel Gorman Cc: , , Arjan Van De Ven , Andrew Morton , Vlastimil Babka , David Hildenbrand , Johannes Weiner , Dave Hansen , Michal Hocko , Pavel Tatashin , Matthew Wilcox , "Christoph Lameter" Subject: Re: [PATCH 08/10] mm, pcp: decrease PCP high if free pages < high watermark References: <20230920061856.257597-1-ying.huang@intel.com> <20230920061856.257597-9-ying.huang@intel.com> <20231011130822.dmz4nuidfyk7w34q@techsingularity.net> Date: Thu, 12 Oct 2023 20:19:27 +0800 In-Reply-To: <20231011130822.dmz4nuidfyk7w34q@techsingularity.net> (Mel Gorman's message of "Wed, 11 Oct 2023 14:08:22 +0100") Message-ID: <874jiwf2y8.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 X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: D67A740022 X-Stat-Signature: 9mrz3g3ic1575xroidxhtz9uhci44zqa X-Rspam-User: X-HE-Tag: 1697113295-227472 X-HE-Meta: U2FsdGVkX19Qv8JRc46+jPRvGIR56bdLs/+CRs1+ICwEvZh9mBOhaj5V6VZQlF27HkHLarFzErrLPyfqdUIcJTBI0E00sQAjHGapwPBKskraEhDqLD/wq8f9+w36y+f4YTMb9vzo0JiU/zlM1tFWDky6ILUbijbXluiokpQuxteYBx/D4DsvX22KeHbA5ZRM6cbTu/F2AsKMGGv/puYCXq9SDhY3K/vnO2JuHjtHUR9jZ4ogXn+5Z8fQVj+VckfbYoi/pH7qiHGnOhHbpw3GiaIUzfll6Jw9Je47KJM0trusuulthlw/zPHVGSa6H+8fIXa/3CbEVwoKQiLm6C3skUfyPGPDgO7o2OgTNDXilygjuw2IAqTDU22r5Ve9KJU+4LW426EUO2hVknYsITiSD31odV+wSWeX4+WigHWiZTqDMwW36k3Sbnmc0BW7gwbFhnVjl3fv1AfbyQEz61Vk2AONDn2xN4PSro9uLqrRgREvwCTkaT0IScnDRCvrZeCOPF4urCiyT2mcmMnFrNDpJOgiIEIiZpyS+03HQUkPd1rLWI5OFWQaD/rIuTmKz3znX3axO69/L6lG+OtH1Kip9cxJNjlw4093ndCU27gJ+Z2h5QkBFkrfKCfvPj9NddaKyLd0R+aHkaj9rqqYLnXpJrmApUM4xrKRnSpX+z+cxuedE1bfp12ToU4A0Z55xkXGNj90Jgv/2g1lOBc4spfqMYfC4oajeJBCIsekdFlSegZXWTFJJp2osBV0en5bnpf9cDrX9e9gzx4lTv9ZIMfcvp1UKRD8TPGLXts62JJ9cxMAO6DpqqRAnN1u/NHY0jbGuIdVdudwx8wEojwlz35nLU0DuTJcIlooSMoFcJd8V+jP9yfV3RtXHD3yjzhOvsSVD7u3eJCM8MPf7bDeNj0tLBZqVoFLFjZdc0pfqyWD14SVtUHw+wgbXcwBPfkPvNSKtGvm0prDT25rdrAM5m5 ExOKQjiZ oQyUKHBwt9MHLrcG4M8R2HulmJLbEcX4tyX+ftcSsIOvQcgJHQFMpsjIMvnobTeZZPZSdJGtShxg/BbWIjvocxxEutr7ee3R7kxzjt55gmU8ffqiND+t8E/i/TjgYoLrqpUj04O86BmWnRoQC3FsYozC7ibtKKTsFwR80acKor0FwL+kwlMmOmEuINS9FZl1MMbNrl5lCBWLco/Brb64C1Qpl+08175uLTDj+RLgumrLbExSdxcMlPxmuA8pJKR+ypyyvQ/ggnGJgN8wirlJTnPKEBps8f7qLQxx+VFokyiUPKntc1q3BbdwjOBi/hbUcZ13A3ZgkD9fGIxREEf86aZchbySFd+F+lgCebmh34A8tEnA9u8goQ4cq774Y6er1+crqkrR2V5K7JajXilTCxdBw6ZnHvUEnvUFMNCoGgY08iTioSI01MLultaXTl0CXxUNfT33zybeIIm6LM2LJ+SuXY9TQuU2Wo2OEOAp2wyXhL4BT8C/DmpdLRPXCFQkBJpz8eJ6uXtWcPtv8oYlsSBToShwEwkIgh+8tZAhVhHqhM+k= 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: Mel Gorman writes: > On Wed, Sep 20, 2023 at 02:18:54PM +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 | 22 ++++++++++++++++++++-- >> 2 files changed, 21 insertions(+), 2 deletions(-) >> >> diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h >> index d6cfb5023f3e..8a19e2af89df 100644 >> --- a/include/linux/mmzone.h >> +++ b/include/linux/mmzone.h >> @@ -1006,6 +1006,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 225abe56752c..3f8c7dfeed23 100644 >> --- a/mm/page_alloc.c >> +++ b/mm/page_alloc.c >> @@ -2409,7 +2409,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 */ >> @@ -2459,6 +2465,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); >> } >> } >> >> @@ -2765,7 +2775,7 @@ static int nr_pcp_alloc(struct per_cpu_pages *pcp, struct zone *zone, int order) >> * If we had larger pcp->high, we could avoid to allocate from >> * zone. >> */ >> - if (high_min != high_max && !test_bit(ZONE_RECLAIM_ACTIVE, &zone->flags)) >> + if (high_min != high_max && !test_bit(ZONE_BELOW_HIGH, &zone->flags)) >> high = pcp->high = min(high + batch, high_max); >> >> if (!order) { >> @@ -3226,6 +3236,14 @@ get_page_from_freelist(gfp_t gfp_mask, unsigned int order, int alloc_flags, >> } >> } >> >> + mark = high_wmark_pages(zone); >> + if (zone_watermark_fast(zone, order, mark, >> + ac->highest_zoneidx, alloc_flags, >> + gfp_mask)) >> + goto try_this_zone; >> + else if (!test_bit(ZONE_BELOW_HIGH, &zone->flags)) >> + set_bit(ZONE_BELOW_HIGH, &zone->flags); >> + > > This absolutely needs a comment explaning why because superficially a > consequence of this is that allocator performance is slightly degraded > when below the high watermark. Being below the high watermark is > completely harmless and can persist indefinitely until something wakes > kswapd. Sure. Will add some comments here. -- Best Regards, Huang, Ying