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 D77FDC021B8 for ; Wed, 26 Feb 2025 06:54:40 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6B555280007; Wed, 26 Feb 2025 01:54:40 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 63EB1280003; Wed, 26 Feb 2025 01:54:40 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4B81E280007; Wed, 26 Feb 2025 01:54:40 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 27559280003 for ; Wed, 26 Feb 2025 01:54:40 -0500 (EST) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id CCB0E140D2E for ; Wed, 26 Feb 2025 06:54:39 +0000 (UTC) X-FDA: 83161182678.03.FCF3A04 Received: from mail-ej1-f43.google.com (mail-ej1-f43.google.com [209.85.218.43]) by imf28.hostedemail.com (Postfix) with ESMTP id BB6EBC0003 for ; Wed, 26 Feb 2025 06:54:37 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=T0NrEoli; spf=pass (imf28.hostedemail.com: domain of mhocko@suse.com designates 209.85.218.43 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=1740552878; 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=mxdnQu4OppZypSyPYCwHncE4Y/i+candjfsSkpyUwTk=; b=3/lzzYU4TaDiOHXG/l3pj0Aa2xQPHuhWhHBGKqG1lXef0k1yeeLzF3dZiUCtnEYiI8a/TX HRRzKbBejS/nvusDQN8Raix1deNuEXbGebPmeUGxxhbEglxOiINV6SfMPD+yYWez3LFWrd SDeinaSg6xeJurqUZdSdWA6woOIw4+Y= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=T0NrEoli; spf=pass (imf28.hostedemail.com: domain of mhocko@suse.com designates 209.85.218.43 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=1740552878; a=rsa-sha256; cv=none; b=oEbWT4Y0AXQAmHRQTAYb1iG4svFqNmjoPO3P1Mdmd8GthxsY+KRsgMAcoKc1Lhe0oBy7s9 rDFEjCeNDFqLCJ518O9+SwbwAHf/hZmmsmSY5ym27ruu64K9CxhRy6LIi9mTz9pAiP2tFm +GkKzuOdpAWLB0N2W1e462OKkfBqTbk= Received: by mail-ej1-f43.google.com with SMTP id a640c23a62f3a-ab7430e27b2so1005271166b.3 for ; Tue, 25 Feb 2025 22:54:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1740552876; x=1741157676; 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=mxdnQu4OppZypSyPYCwHncE4Y/i+candjfsSkpyUwTk=; b=T0NrEoliXFSCG1P1uFlUIViXFXn5ivInrwFPCXoSFly9c/GzPHtNIJ6BG46U9A3zxC OHjfikg08/dOdEaphhz1YpOyNh3Z3DQjRz/AKPbFcRw3xYzTgQxxUC+VxjWXaRyJcM2K QUvGNEeuwVACz4RrVku58MMHdWbiOTkepYTpLO5wdqmUAiIDAser/GlIivC9S4FJWkyl xywaP0XQm3HKkkcC8Hd9BXUTwjYDEoQGRTDzhz9K6oti+gE5w/oqoGMq9hIxgkAOIi68 VZrBZW7dkH7AFQgdU8Yzy8P5e2Pu1NLk7IMkMGyXGjJ4Y43/KZDx2n1kR4LUmoGTCEEr yabw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1740552876; x=1741157676; 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=mxdnQu4OppZypSyPYCwHncE4Y/i+candjfsSkpyUwTk=; b=PVggM/m3emNUTNcYjcz3xZqA4twWq7FIbjatnARcUPjkiPfX9Sc/TQPolKAH203ACt Dv9S0GmpbdkIxeU17eCEg1nV3LXYkfUCUFyDVkV/lzCi0sq15LdMhbmyH9TbBio1t5s9 CJaIHme8tVN2H3IvogsiqWPk051foaqcj05q8GtWmI75Aa9RJe/ukiJmXFGk+b2dlLgy 7wjdC9HtYKKRQ75dzzd2fPJ/w+m/19qZcFnddgk1kkMLy7yUVvMBTaw84sj2nl4vRm5y LA1J195bp2Kv5DlV684t9o7pTngbaDzsODSwi6qdjADtRdfTgkD3LPGGXsYkVcqOEHSM N1EA== X-Forwarded-Encrypted: i=1; AJvYcCV9mOCNK8d/jP/EGqt/NIY/jFqUinCEGfEihDg4DvVjzr6DQiGlSfCugCrrrTrNO6heXG3/i/8bRg==@kvack.org X-Gm-Message-State: AOJu0YwsT3SSSKopeDrzTrCqKXqs6OoT1G2e1Bf3CrBJdmE3SZucKsM0 PGj9LXC3nBVZlBk4jAruOkTs1xhCrfmo62xBTXiRQH/TF9q13AtgnvehabFBqqo= X-Gm-Gg: ASbGncvwcaJKfQygiBVpPnnGm32h2imJXK/+O9Aayq9LAJlGbuh58S1N2GrSdmWAI+7 jCnLEjR70cSa/ZeGcji+Qyj7wKsZvB9ZxWAJznn1saQSPbOIXNth5MDw63+gFL3FT9bNfoEkzyd Y5Wk0zgmePjcf+xdrXuwu5m/Rnb+PzU74bzHQFT24p23U+ycwTy2Nf/pqzlvyAhrHHAfd9qa1l/ IUDN8AWi+d887t3j7g9kvrbR+5eANJgn40en7x9wihqKyh+waMQxg8O/f7TKszFRfRfni6Rnqlh 2oOBskRsDyXGKYhx8OAHTEnPqDIlWXdPrTCf X-Google-Smtp-Source: AGHT+IG1QQpjdDpkuXw81+DXU7C5EdQhEI1+UfDTI2CdiomJJ2ayv3kYuWmOXzQFXC2HyuYEYa8cmw== X-Received: by 2002:a17:906:308b:b0:aba:ec4f:fa4 with SMTP id a640c23a62f3a-abc0d993654mr1657566866b.12.1740552876173; Tue, 25 Feb 2025 22:54:36 -0800 (PST) Received: from localhost (109-81-91-34.rct.o2.cz. [109.81.91.34]) by smtp.gmail.com with UTF8SMTPSA id a640c23a62f3a-abed2013973sm273839566b.109.2025.02.25.22.54.35 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 25 Feb 2025 22:54:35 -0800 (PST) Date: Wed, 26 Feb 2025 07:54:35 +0100 From: Michal Hocko To: Gabriel Krisman Bertazi Cc: akpm@linux-foundation.org, linux-mm@kvack.org, Mel Gorman , Vlastimil Babka , Baoquan He 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: <20250226032258.234099-1-krisman@suse.de> X-Rspam-User: X-Rspamd-Server: rspam11 X-Rspamd-Queue-Id: BB6EBC0003 X-Stat-Signature: y9ybh576zje8aiewfe6n3eyekoraa1yx X-HE-Tag: 1740552877-726031 X-HE-Meta: U2FsdGVkX1/cCLGDPaAM8YGTugEDiFzrQ2jeWywkmHO/tNWDFiJyX91WfVeBSH/5EFdYnHbRyXSmWcofHg46TNIg6/wCJ34D9hSNHffaMQj9wVSTAcYPPTEfb/rtb+/lLqVJzey5vOnf1HwG3PlzloHKM3FwVH157fpnFMhXz5jv+5wLXF8AM6kaam1wuLyOKxmt56+pYeHMPARCpSpTtGlAV4RSIx1VcKDKhnb/J0do9U2eQAou+qZuhgwLoCW6TP6jbyrnZ33IYRkV9rHcKiBTIezT+9teyyIOQBPO4b3AxWajnin2Sl+Hov0TdzbkChQUmi7UBm9ItVMytdtz8Z1M8pei1x9FyBvwMCDAgbvSn/uNwqosYROUGeMx6QVPMYgMuy0O3dpdu9enU8cNxdDQUmUXULFBtuNerLUwczu3amEIG74z7INWJdPZWPja/na4Nn59pIzrC+NBoOwmTk/b/0mrqJEEKWkY271SK60ZflNg9h4nZBnmD4AfBt9tCt/VLrXm2UIJJdaGcaMm/VB6rLCKeeHb5H1ok1MMzmoDaTbVVIPRnbxEArQkQ5AfxfHihb1P1ORY8uiEARSnRm4AadbOTkO7E0LbAas5ASbmLMSaWNnL4+/YntawcCROBvXWrRlYraVEZAhR4/huPZirA8JetO9vykKCvKa9zUC4Q0X2cr8fnaFpn6h9aVQz5atUfCbMH6Cutf8otvsvoJzYA/Oha9LONAAzBXqgSE/906pn3IGvIXz9GbUJ44ZulZ91qbCEmqllZf6L0mllf5iHt0gYLHVasx67f+prBKJQhzQvzG5sgU/3a+A0ezrq1ohvtD6smgoV0EX+y2wQ3zVVJPcoegEOsomOExY6KVEB1KSIY+vjPPNq7xulKFDtB8yHHTVav+aEqZ0Gd7WSGFJoJC/B9aXJQOWfseqXaGFZs3GPWSIEmcbeJRiXDlWoJsuauXQ+vfb6ruy9Xng 2TodJ2sz CMJ1gBN23w/TzMsmPesiT9yJ7rJscine9yQPL5IFH88RvgysC/yL0T8v/J1qxTu/WPPrx84uvqUopxKs1/R0v7s5YGed08wm9shOXBRANUZLkDaZ06HQ/gAbh+PvgpDdcqoXrejdSfKnZ6PlnuC7x+ABm6z/m82zD1NYUdOh2Bj+UmpxfCtaJIYrhz9Gxiy7rEkXJnd0aYEsKWcRS0jfBaq+wSE4mHI9RQjOZWEHL52ioU5YUIlmn9C+oZd31N98VhuEICM+YwKrSwT/E+u8qvPolKJU4qKkiv9bOqrn8pT1mPFqAS8TZHdqHAF65YAm2n5wRv7GLOL7pFADbQr4u5WIGL1e2vCiijb+zkdOFDhQ9EnLNlCpBwoswAZaawMGyqda2Slqx6h0wNE/B7k5MrjOpRON7mmA8XkAMG8FO62cH2DuUSVGwqx5D7C67ohxfyMRWAIhi+7AsjpMDFALC4rtiNQ== 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 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)? 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 original commit was introduced as a clarification of the > /proc/zoneinfo output, so it doesn't seem there are usecases depending > on it, making the revert a simple solution. > > Cc: Michal Hocko > Cc: Mel Gorman > Cc: Vlastimil Babka > Cc: Baoquan He > Fixes: 96a5c186efff ("mm/page_alloc.c: don't show protection in zone's ->lowmem_reserve[] for empty zone") > Signed-off-by: Gabriel Krisman Bertazi Acked-by: Michal Hocko Thanks! > --- > mm/page_alloc.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/mm/page_alloc.c b/mm/page_alloc.c > index 579789600a3c..fe986e6de7a0 100644 > --- a/mm/page_alloc.c > +++ b/mm/page_alloc.c > @@ -5849,11 +5849,10 @@ static void setup_per_zone_lowmem_reserve(void) > > for (j = i + 1; j < MAX_NR_ZONES; j++) { > struct zone *upper_zone = &pgdat->node_zones[j]; > - bool empty = !zone_managed_pages(upper_zone); > > managed_pages += zone_managed_pages(upper_zone); > > - if (clear || empty) > + if (clear) > zone->lowmem_reserve[j] = 0; > else > zone->lowmem_reserve[j] = managed_pages / ratio; > -- > 2.47.0 -- Michal Hocko SUSE Labs