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 6699BC021B8 for ; Wed, 26 Feb 2025 12:01:34 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id BB7B8280019; Wed, 26 Feb 2025 07:01:33 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id B67B5280015; Wed, 26 Feb 2025 07:01:33 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A0806280019; Wed, 26 Feb 2025 07:01:33 -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 28E14280015 for ; Wed, 26 Feb 2025 07:01:33 -0500 (EST) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 633851C92CA for ; Wed, 26 Feb 2025 12:01:28 +0000 (UTC) X-FDA: 83161955856.03.6585F6C Received: from mail-ej1-f45.google.com (mail-ej1-f45.google.com [209.85.218.45]) by imf10.hostedemail.com (Postfix) with ESMTP id 20101C002B for ; Wed, 26 Feb 2025 12:01:25 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=OK5pvhu+; spf=pass (imf10.hostedemail.com: domain of mhocko@suse.com designates 209.85.218.45 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1740571286; 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=2asT3GLdxpceQcvmAJIapb/jWpQfnjZCcfGAyyy9Yls=; b=hV6mizX54RH4cqR9FYK5m1CZqUGvoejMqSohXdIIIyb0s1nMcLsu7AGe4xappgTYTQLL78 cgzPlguxl2pp5nDvw6os91wO5LQfbhntWfuP/46t0MyTwKcEqDmgMtiPUvVApe/ZLiksAe DEloy0EPypzfcKdMRBTvr/tvgKuXEGw= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=OK5pvhu+; spf=pass (imf10.hostedemail.com: domain of mhocko@suse.com designates 209.85.218.45 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1740571286; a=rsa-sha256; cv=none; b=emERhyUN9w/CauW4hSM2wLz8lmY830R1yWnGm9e/n8u6MMIzHmHXbXGKVMXW7UIfBCR9AV PObe0UxbpB7MMvp1OLsxn6G52Eg+TdP8HT6LteaoTktaXvrapoFRvlM7CIchb8ExUNxNBM t3bDtjM1E9hPgA6jjXAHRHhlYw0Z0w0= Received: by mail-ej1-f45.google.com with SMTP id a640c23a62f3a-aaedd529ba1so777761366b.1 for ; Wed, 26 Feb 2025 04:01:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1740571284; x=1741176084; darn=kvack.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=2asT3GLdxpceQcvmAJIapb/jWpQfnjZCcfGAyyy9Yls=; b=OK5pvhu+jnReJkvLfGzKJ6qCOkS30+iwW2mPIyjnwVfVLclFDJnkSV1MfPh8dYL8rn 2H1lnZxITObFmgApwsry9NhZyFSQFUvuEwJHiAb9i3A6Bn24UiM4a9TrusBEPJudPNCb bZ7eZBz41tANA7nxDGmWi4Dnbx5RggI1gO099tsdKkUD9CSWc87HGvR5nnVBkPTCWoCK ZKOaEzkC3crhrqDGIfDRMtXacSCb4H82o1VcVacoNK+P5+z9geBUV5XKiir7ek7m7Kp6 Avw1b6QJAcRai7kiqaLn1jFbANJS9FIeHDzBpHFnmz4QXDkfeAfaFKLaoYWg/AXpdceI UhQw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1740571284; x=1741176084; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=2asT3GLdxpceQcvmAJIapb/jWpQfnjZCcfGAyyy9Yls=; b=PWnHPwWH+51pFyxHXYfA1r38Bb7IgVGE/QxH5hOH6MpfhAHdogqYnCfhHc2sGKVfFd EcIJSw2GYDSgucxWN/1dB2TDVN6U+FYMs7vwkQcU5MDaPiVVxpANkQtOIAudi6di69Nf p0d6hpDbSkA+hWht6G+1RbP50j0IqBmAqIAeIGoORaEbC6DdLuSiWlNq3RG3ybfbmhZp gfd5RCE0TRw1Q3OB5zvCRCWJZ2F66Ph1fcGEBNYwM9Cd02vKZhocLGjsnReofcZUCaoU RPR1pjjTMLwQ9F6bss/dZCxoj7BlCf6axRJab60jx6hOirVXY6jrPlnFMLibHWc90ARo JQFQ== X-Forwarded-Encrypted: i=1; AJvYcCV2AtNinbPTb0wUprT6DGtN1CLnuM63miev3gMvUxdRV+9hWGSe1FjVlAmIuLELWIG0om7QjLvj2g==@kvack.org X-Gm-Message-State: AOJu0YwZJ/Nez0lkrez1K9qiht4/xNoO9Y24JtiPG1rwIFfr96yGC7Gu mS2FUTcfBbhIW7AnGHyfvJKtE/+oqYOoKq0bz4pYOz/++Am+uen0hoA3LeQ1fp8= X-Gm-Gg: ASbGncvPVVVKJ7n5NRyfWw7BCayhqLCUHfHYmPGzcskXLGtFCnv/2iCLeObktRCYRmm JHKdOhfQ2uszVs/Es2Xra7tZ6kIgPVlCXzEqZX3EYT7C92xWEp8rD3p/5gV1hMRZDd00zlRWJQj KMGFoLxZzczmf9U0bVeIO4tkBFgWTL17vVrgf5NAWaPdGMVs/eSzvxHSslYcSLgnaMAZZ4usd+X PsIrVMMuIZVcElK2wP7pVGBPUEirfIGQaHBO/YFxrmiH5U/cEgMVJ3imP2YekNOxkS+18XhytNk Mt90/lPi9SXGJyhE X-Google-Smtp-Source: AGHT+IH36+n+dJOtx27OsjT3Qcit9ZW8f5X3kVGdFXZtQvz7UlGuQZg9x/Gt/bM/jePqeqcULCKMzw== X-Received: by 2002:a05:6402:1ecf:b0:5dc:7374:261d with SMTP id 4fb4d7f45d1cf-5e4448537bbmr17890031a12.7.1740571283463; Wed, 26 Feb 2025 04:01:23 -0800 (PST) Received: from localhost ([193.86.92.181]) by smtp.gmail.com with UTF8SMTPSA id 4fb4d7f45d1cf-5e460ff8629sm2672300a12.59.2025.02.26.04.01.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 26 Feb 2025 04:01:23 -0800 (PST) Date: Wed, 26 Feb 2025 13:01:22 +0100 From: Michal Hocko To: Baoquan He 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 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 20101C002B X-Stat-Signature: rg7xp4irf8j7oa7xu6ofyz366bed771o X-Rspam-User: X-HE-Tag: 1740571285-656932 X-HE-Meta: U2FsdGVkX18I+KFCuhMkwjbu3i1O+FcgdfQoU/WvJlzDdzc32OARoWftYiR8m918lM8zVjRbAaiea2tGBIMZk7mYkpi2mZUNYacZVZX8IAQs+31eKv45LRj+X9u5kHyVfMTR3XiDLQG5pVwGJxaFXUQSC99ZEC4rTSRpJu16hcqoXXgI8bmGwLOZ+W7SSCDUDpSUgl1pomXFsSSfF2jod84DKMNj8Qv3nFVse2ynzJOyOR5oxX1GeuXOVzDgwsG9EP9KXgDyi8teInsRJy3+oonOXAaMGmKnHGspruRfONKSzYQIjZlY6Rqfd5vRQ2meokbBrvv6jsFgHHFjjy4OKHhgAKVHIE4GGTHTKoC2yYc+eJBT//DrAH2KYoiq2nmCfxa/Q1eV7qF9vLSFyxBjvCklp0+5I9+sBs/oODoCitArZpUdixXOa8++dLIKVHBvRu8dAOlN5HbbXSXV3MFD2tGcWKWrahiJN9v3u7+tClTAaHprq20vOnWHY2r4RJEoWZ5rOFVR6wEzxvu2ugMIpzt32Y+cLnCXZMhg+V0rw3nW4Vc7petGBLPUiADXV8vRAOSMub+3bFKyXVGS7p9G4KBvt7olM9ZhAxUB1RCp2P9XR4uedISaX8ueFN34wzatW8uVLB3OD02oKo26F5BfXngKxYmdy4oakWVHhlhKdj08QjALQ97MlYymHUNrewKLEEyAol12w5pbBKGWc9h2rwX7m14bPqefwu4nbbdGkWC+z3aeYONMxEQyeVulhOb8C9r2lRMT2kQCWruqFu4VYvyGARdvzn3tS6tciGiiBF9Bmjnnb5NMLRIrAtt5QPJgjzPfgW2FdK7ojXm2AXXb5ZW6RN+VojGhkM900+LVhXTOh381AFfbU9RWFj2gCTLYRDGKmZt47V98BwGYLnOhQG3ZqT5NdkV6c08y2U+OYuzmHgqk3qiTEA0oRhQhetSJPfMWbJF9vld2M0lW43p ql6k6DYF yZvckJBMS74/K8nKpAsKx88Q4L0trhP1UQ9EIoiYZn1ncKh4UNfbB6EEoTE4TQYsGg6rVLuNuyhMlxnEpqsl4bYFtI+M2ubHXqdyhUtahxXzH52sKRKTg90XGQ6a3RowJCWG0Or6fZjeTYp1l9h+C31IxcAFk+wXOJQ79odkOcQUbgf686YxKz5/lZiKMU/P2uS/Ox5/1skhCnnr79OvaCB7xnGu4DH9yKujZL6zNiOtwEU5QGuQk0bfGP6/8akvvTYQEhMypWVGxkCWInpYFkhVUv5Y0dPXh9RCQG9cS7Q4Gsv+9jFljgwf2SkGbR9zkTEbOA71z+s32/UMbKcfZMcggblWBF8C/0eoFlSjYuwFxY5c= 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 Wed 26-02-25 19:51:12, Baoquan He wrote: > On 02/26/25 at 12:00pm, Michal Hocko wrote: > > On Wed 26-02-25 11:52:41, Michal Hocko wrote: > > > On Wed 26-02-25 18:00:26, Baoquan He wrote: > > > > On 02/26/25 at 07:54am, Michal Hocko wrote: > > > [...] > > > > > 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. > > > > > > Are you suggesting zone fallback list to interleave nodes? I.e. > > > numa_zonelist_order we used to have in the past and that has been > > > removed by c9bff3eebc09 ("mm, page_alloc: rip out ZONELIST_ORDER_ZONE"). > > Hmm, if Gabriel can provide detailed node/zone information of the > system, we can check if there's anything we can do to adjust > zone->lowmem_reserve[] to reflect its real usage and semantics. Why do you think anything needs to be adjusted? > I haven't thought of the whole zone fallback list to interleave nodes > which invovles a lot of change. > > > > > Btw. has 96a5c186efff tried to fix any actual runtime problem? The > > changelog doesn't say much about that. > > No, no actual problem was observed on tht. OK > I was just trying to make > clear the semantics because I was confused by its obscure value printing > of zone->lowmem_reserve[] in /proc/zoneinfo. > > I think we can merge this reverting firstly, then to investigate how to > better clarify it. What do you think needs to be clarify? How exactly is the original output confusing? -- Michal Hocko SUSE Labs