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 4FA14C021B8 for ; Wed, 26 Feb 2025 10:00:42 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id BD48F6B008A; Wed, 26 Feb 2025 05:00:41 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id B84EC280003; Wed, 26 Feb 2025 05:00:41 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9FD50280001; Wed, 26 Feb 2025 05:00:41 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 807496B008A for ; Wed, 26 Feb 2025 05:00:41 -0500 (EST) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 2E10B1C91DD for ; Wed, 26 Feb 2025 10:00:41 +0000 (UTC) X-FDA: 83161651482.11.F9B14FB Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf13.hostedemail.com (Postfix) with ESMTP id 1029520005 for ; Wed, 26 Feb 2025 10:00:38 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=LPu0a7XO; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf13.hostedemail.com: domain of bhe@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=bhe@redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1740564039; a=rsa-sha256; cv=none; b=73so/YqE8b3D24fx1kqR05zoravXcHdMXb/NE5Xcrr1SnXp9/Zv+4I2TYf8/IJWzX6wP9+ rXNNbpp0+PmcnL8ZMfd6AzNNxkhN67hktS1gJj9RXdpEtwcISrZdWWyc3gDD74vjJ8IYrX pZ8HNx3sBFQwouDQ0EvoNGO2rK/+asE= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=LPu0a7XO; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf13.hostedemail.com: domain of bhe@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=bhe@redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1740564039; 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=HjhDfPm7Ga3YgOEj2AGLDnnFGYWHcJ+OGbWiuQEtOSs=; b=XR6tKrykLDPNJqcbn6D1cjw6Tp3HJCwegGdTaG25GDIns999MUl1NcN8pGVp8qioRP+msp xXcmMIklnRO5BiVjUgF1THG4AlwW/AlrnkmfjaHFRYLVW5ajiHpnNA3WF74dmdH7LDfo2S kATxNtUKyPzYBTo4zNmiaUOnprUDRrs= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1740564038; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=HjhDfPm7Ga3YgOEj2AGLDnnFGYWHcJ+OGbWiuQEtOSs=; b=LPu0a7XOveVaOnvTKuZLPdkp34cXX1HQ/ErwlTy/kXB0HThMiykuNB/BUvjUX7SLepeCQ9 2Vv8qqZ3GVfEtpasSfmicpP1iuVhv/1ji2NEAoSqFCt2ld16kAowBIm5DHjPa750l/iSfH Oapxc7Sje5h2mZo/QkapmVpUkwvmlGY= Received: from mx-prod-mc-06.mail-002.prod.us-west-2.aws.redhat.com (ec2-35-165-154-97.us-west-2.compute.amazonaws.com [35.165.154.97]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-687-PpUTAC_lOd2HZsg7DSBwPQ-1; Wed, 26 Feb 2025 05:00:34 -0500 X-MC-Unique: PpUTAC_lOd2HZsg7DSBwPQ-1 X-Mimecast-MFC-AGG-ID: PpUTAC_lOd2HZsg7DSBwPQ_1740564033 Received: from mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.93]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-06.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 33404180098E; Wed, 26 Feb 2025 10:00:33 +0000 (UTC) Received: from localhost (unknown [10.72.112.127]) by mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id A562B1800367; Wed, 26 Feb 2025 10:00:30 +0000 (UTC) Date: Wed, 26 Feb 2025 18:00:26 +0800 From: Baoquan He To: Michal Hocko Cc: Gabriel Krisman Bertazi , akpm@linux-foundation.org, linux-mm@kvack.org, Mel Gorman , Vlastimil Babka Subject: Re: [PATCH] Revert "mm/page_alloc.c: don't show protection in zone's ->lowmem_reserve[] for empty zone" Message-ID: References: <20250226032258.234099-1-krisman@suse.de> MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.93 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: EA8j28eATpFCsQ7GQDCVEhGpylyVhVz2btU-SMOV59c_1740564033 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Rspam-User: X-Rspamd-Queue-Id: 1029520005 X-Rspamd-Server: rspam12 X-Stat-Signature: n676c7h4j8y7cw7p4zhkgp86f3tkumcp X-HE-Tag: 1740564038-342815 X-HE-Meta: U2FsdGVkX19c2pNBX4utoElFPdckrFvl6j0Y+WbMqg73B4WEzdsnlb7f1/9ctEErRSOdYD5fU84pvayiBc1uVDRZ8WgIQpUrSNUAauddwYiYPAzJt175HKWlrL54bz1B8lGnJhBvOXqDppp5YDGF4MfQuVVFSto7jAWamwdvHpoICBxIQzMLsn9e6f7PC3qEd1iCjetRbCQZBk2PAOR0uyO9lJwS0i6rgjTdiNNv0yYPC2ayfij/SAJKqAa+r8zYPM9ebhm6UQM9sSAQkbcmaUcbOG+5RaKGugHe3Z99llrtgOAtc7pwF3dcchcYomCxhE3BDLAiTz7hIqp2Qq73n+rwIOsiL3COinCaBUV3u0u9jdlBN+xj0cPCqO5xMRFaXRZPN0vWewa90SQ8QvdjERo2hisX7X7KeGqSNZum3oiKPow8cn1daHQ5sQkom2UFEJXFCXv9KCbV9iJQDfbbCger+BFF4NYrFVPL0zb0CKYgU0eRYSNMjCPnctM5Hb3mVRhqmsGqumD2vef/YgBGmnoJgnP3f0MnW0hWd5XBrZBfzZ7E3PEEuhQO8BZXi0QiYYNWH1/GvVDGk1kTa4VWeVaJiuHFE0KlI+tLkqsDP8zp0VFLKfwjs5l0WCh4iKJ3US5aBj85yDTKwl/hzkrnPIcoa/XDl9fSJM9T7kSf1pO9z6yYF7A+x0ySsWm6WSUOoV0c/NgzeSqdHvGXMPbDkb+d3QFOtM+QZbyevooFUabLS6SsMqfLXiJl/B31qNmoKJNTRwA1kSgEzWzQXi9Rl2xGwMQbJ3MpLJq6SRAb/G+BToCzQOSXeiBduqzgPmQQrPnETfKdvn2PEi0EFmX8szvcxfPPYmN2xbfTmDmPp+EVazdTxLZ6ar8rK5VfhbnSzT/ANbIAcaASD17vrhiOeYVDG4J3of+qs8TO8yKrwzttYm87v8A+OthivEK8pZxz5JbF56rsSVQYzgWwAx4 bdiljPDA gHrP/kAF8l865LT03Hr0tfXPzdek6tJ57VNNpYsRuZJB0LmL5gwGHRbBeFflLxO/yKnNnJCRdQXACYV5rEZ9q+yDCABhHeuppKhFnmjLQDl1iUmSrg8jbdBxSYhwQ2ejdQNSst3kklIKEM2WmcGb/k2Jpzt1MbgNqHpFwl2OJYC2UGcZ8HEuRUMkMcqPx2xvE5lO6tDRg8qzGR62FsVwtv6SP8sVp4sBhHFIGzkZwBv2lxtK559IzkLoj7FutsxQKLgEjgxrWgVOgo0HHLCjCJhIYECY73S7Qp/P09R70wLMFU2CuhRM/Dux8uBDMj49TMecnb1sjmHac5a/mgPnWfis70GFr+fvp94QjpAiujzdIJM2UBBVmM3PmL3yNbcGELXiEyNkP22fGa9Q2bewNjiYGxXn+VjfHO8cFlQlFcT6vi4CTLhbYm6uYZYjoIszF8dC4r0uUQ0wdQ3dp6Vm5XQrdXCir+J9whZuxxFzmuYTMDwQ= 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: List-Subscribe: List-Unsubscribe: On 02/26/25 at 07:54am, Michal Hocko wrote: > On Tue 25-02-25 22:22:58, Gabriel Krisman Bertazi wrote: > > Commit 96a5c186efff ("mm/page_alloc.c: don't show protection in zone's > > ->lowmem_reserve[] for empty zone") removes the protection of lower > > zones from allocations targeting memory-less high zones. This had an > > unintended impact on the pattern of reclaims because it makes the > > high-zone-targeted allocation more likely to succeed in lower zones, > > which adds pressure to said zones. I.e, the following corresponding > > checks in zone_watermark_ok/zone_watermark_fast are less likely to > > trigger: > > > > if (free_pages <= min + z->lowmem_reserve[highest_zoneidx]) > > return false; > > > > As a result, we are observing an increase in reclaim and kswapd scans, > > due to the increased pressure. This was initially observed as increased > > latency in filesystem operations when benchmarking with fio on a machine > > with some memory-less zones, but it has since been associated with > > increased contention in locks related to memory reclaim. By reverting > > this patch, the original performance was recovered on that machine. > > I think it would be nice to show the memory layout on that machine (is > there any movable or device zone)? Yeah, printing /proc/zoneinfo and pasting it here would be helpful. > > Exact reclaim patterns are really hard to predict and it is little bit > surprising the said patch has caused an increased kswapd activity > because I would expect that there will be more reclaim with the lowmem > reserves in place. But it is quite possible that the higher zone memory > pressure is just tipping over and increase the lowmem pressure enough > that it shows up. > > In any case 96a5c186efff seems incorrect because it assumes that the > protection has anything to do with how higher zone is populated while > the protection fundamentaly protects lower zone from higher zones > allocation. Those allocations are independent on the actual memory in > that zone. The protection value was introduced in non-NUMA time, and later adapted to NUMA system. While it still only reflects each zone with other zones within one specific node. We may need take this opportunity to reconsider it, e.g in the FALLBACK zonelists case it needs take crossing nodes into account.