From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pg1-f173.google.com (mail-pg1-f173.google.com [209.85.215.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1FE102ED870 for ; Wed, 24 Jun 2026 14:24:37 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.215.173 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782311079; cv=none; b=ikXOdQqNPnIJhxTDLzpBwnB37c9LuD4KqTsWcFaNmyC6h23kXy+BTO8ZL/osvbsqu6Nk5CPMhbiiz7tpIOFOUfXayDkTWRqLQIjf89q16AoUz/wxtFa6XAT3yhgcG5wyLmSyK6NTEe1t0Fj9I6w3bar+kN/I5WERCmIjhgVZa20= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782311079; c=relaxed/simple; bh=+GvPHtbjBfoeFHgSA3GIQrRzol9K7XiFhRwqivJDapw=; h=From:To:Cc:Subject:In-Reply-To:Date:Message-ID:References: MIME-version:Content-type; b=Fy0m/9eRmHpDn73IHrqRW23ni3ZYB3I+uk5E5MfqTqEjYa+WlUdXmpjDs/G2wsO4QIMtpcCeQoyywTrVUeLcS/QvMCUgNiCgGQdPcrbo/ZxiPhO4Wj0GyxZGx0N2qaXa8ZXXBifXxLQnlPMBcOz0/NeezDzSgSG+VD/u6SPkD0A= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=AcMSf/jl; arc=none smtp.client-ip=209.85.215.173 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="AcMSf/jl" Received: by mail-pg1-f173.google.com with SMTP id 41be03b00d2f7-c8d00e782d3so431359a12.0 for ; Wed, 24 Jun 2026 07:24:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1782311076; x=1782915876; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:message-id:date :in-reply-to:subject:cc:to:from:from:to:cc:subject:date:message-id :reply-to; bh=bC7GeOhZGz0je76Vr4XAaqeVuPBssFAF57vnDxsL79M=; b=AcMSf/jlCJU2ILuSt+66WbpetxY2HadsHQVxaA/1YzNOwOVJf6n4RLaG1DmmcY6C7p TIlPgl5GFj2+dPxYJTMwPia9v9Oh8ViLz3dd8+7bhnGkU8x2iGj0nQxSfc+MsXKNj/AL x0mJtdLNhk4c2+6dcqg5wYXcNiPXJO1vZks1nY9wk5yS5gzhdt+gneIE3OI5jHv4Xeaq DiReOB/Y4FQHNP5xcG8OzvSCbTqCISOt70ReiblXb8Pac7claoinWoXJFNrsMshEt589 fFCCiCHURgnayZiapliKnusbAgNylNCa7+XnbSDGBFbW3uneBo7Fbi/kvv4nOj1QPDJp fAXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1782311076; x=1782915876; h=content-transfer-encoding:mime-version:references:message-id:date :in-reply-to:subject:cc:to:from:x-gm-gg:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=bC7GeOhZGz0je76Vr4XAaqeVuPBssFAF57vnDxsL79M=; b=RJFjSvQCSeg+O32u/Ftqp0Y3/3XHqUjs1s78kR/zBFlUA0GIrw7wv2xG51VMHF56wi +PsNwemtWdWsekxGSJt06+S+Z7ZYy32PvMA8/fGkyRxc1P9/Bh/FGn/aBn4t7gBs4fGp 5mDj8tCDyPkPAFcPtMFQqoG4Bl8qdHTSieFv3+LiFMxbSy8KQ+hDkNvXLcS/Dn4Xh2nj DZthHk3stIw43Rh5HTL7IKoyk96DfaNJIgPzbhcU7iBSBCwPIbgxVgaAx06RcJqy9ug1 3AgFxow2AeSY36et5lAo0a/yaD5Hqt7NBtJV5707ayKuqrB3Qw5GjlGFfW1rLTuiic2E EhyA== X-Forwarded-Encrypted: i=1; AHgh+Rp5y1Sqwas0T7wt7lERw/7iJuNqvL4L+3niK7GxS5YZiM5NUZVtl5SOnS0V5hvch7aIXXSaneFfTs91I3s=@vger.kernel.org X-Gm-Message-State: AOJu0YxFE3mNm07ZPfDxpQsbARKYUKgPtxji/hzl+ho59pwZVv4HB/8R 9IuWri3u78AUqwg91UeGecCCfg9PQM+PFZhhlQq6HvDy6b3njnBQP/bB X-Gm-Gg: AfdE7cmgS1e8yZd5xw9jJXVxtD9jNM+mMmAppOQl6vvpFVzuFb2vYy9BFJ7sgOI66rY mXaHDwWny5zV2X12egF+/+pcDOGJ7EDqG6TeoXLdA69/BvpmzQOnewhM6p7JSZrYLD5/j0FjJFO O/O+ayZ0pBhOUVAEpi5YyJ+/8YvGFmyOnWQVFCMGdGCasNRpko8Dn1dAwj3iYKgAsQEfj+V7Dyf uYf64WHsCbKyvH7PBgWnMXVraH17R74xuZMxu4cV+PnnKuIOTvxWjHBBYTsvvTZEM9owe8m79qb FIRqHqtarykJ3j3wZNJWsQXWJYeBibek5g3zGoUey2kd6umkMlO8+qmyuOCuzXDz/td79TfgQNj KoJrw39Wgf8dYo5W2OpAffLcu0WuDlP8v/IbINxfSz1JqqpDH2HCCeyE//QSd7ANk9SMEl267X9 lQ3oloXqCEFJiGPps= X-Received: by 2002:a17:903:1d0:b0:2bf:3309:ecce with SMTP id d9443c01a7336-2c7e15804acmr39177245ad.28.1782311076310; Wed, 24 Jun 2026 07:24:36 -0700 (PDT) Received: from pve-server ([49.205.216.49]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2c7439f86aesm135035155ad.49.2026.06.24.07.24.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 24 Jun 2026 07:24:35 -0700 (PDT) From: Ritesh Harjani (IBM) To: Salvatore Dipietro , willy@infradead.org Cc: dipiets@amazon.it, abuehaze@amazon.com, akpm@linux-foundation.org, alisaidi@amazon.com, blakgeof@amazon.com, brauner@kernel.org, dipietro.salvatore@gmail.com, djwong@kernel.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-xfs@vger.kernel.org, stable@vger.kernel.org, vbabka@suse.com, David Hildenbrand (Arm) , Lorenzo Stoakes , Andrew Morton , Mike Rapoport , Michal Hocko , Vlastimil Babka Subject: Re: [PATCH 1/1] iomap: avoid compaction for costly folio order allocation In-Reply-To: <20260624080639.17100-1-dipiets@amazon.it> Date: Wed, 24 Jun 2026 17:51:18 +0530 Message-ID: References: <20260527162412.19922-1-dipiets@amazon.it> <20260624080639.17100-1-dipiets@amazon.it> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Salvatore Dipietro writes: > Hi Ritesh, Matthew, > > I wanted to kindly follow up on my summary from May 27th regarding the best path > forward for this patch. > Hi Salvatore, Sorry about the delay. I did bring this topic up in one of our internal ext4 community calls. And to share some context, MM community thinks we need a better long term fix for this problem rather than patching call sites and/or playing tricks like - diff --git a/mm/filemap.c b/mm/filemap.c index 4e636647100c..f2343c26dd63 100644 --- a/mm/filemap.c +++ b/mm/filemap.c @@ -2007,8 +2007,13 @@ struct folio *__filemap_get_folio_mpol(struct address_space *mapping, gfp_t alloc_gfp = gfp; err = -ENOMEM; - if (order > min_order) - alloc_gfp |= __GFP_NORETRY | __GFP_NOWARN; + if (order > min_order) { + alloc_gfp |= __GFP_NOWARN; + if (order > PAGE_ALLOC_COSTLY_ORDER) + alloc_gfp &= ~__GFP_DIRECT_RECLAIM; + else + alloc_gfp |= __GFP_NORETRY; + } Unfortunately most of the folks might be missing free cycles to work on this problem right now :( - Hence the delay in addressing this.. However - I would like to bring this problem to other MM community members as well who might have an interest in this space. Can we look into the proposed solutions from Salvatore and suggest the next steps please? Maybe if someone can share what is MM community looking for here - I guess that will be a good start. Looking into the table I think Salvatore had also shared a diff for kicking kcompactd in the background [2]. [2]: https://lore.kernel.org/all/20260506123326.17293-1-dipiets@amazon.it/ (Sorry I still have few other things on my plate before I start look into this more actively. But let's hear from others, who have better knowledge than me on this.) > To recap, we benchmarked all proposed variations and shared the results: > > | Patch | Change Location | Avg TPS | % vs Baseline | > |--------------------------------|------------------------|------------|:-------------:| > | Baseline (no patch) | — | 101,979.75 | — | > | v1 (original, iomap caller) | fs/iomap/buffered-io.c | 141,194.20 | +38.45% | > | Ritesh's suggestion | mm/filemap.c | 139,200.61 | +36.50% | > | Matthew's suggestion | mm/filemap.c | 143,863.82 | +41.07% | > | kcompactd background | mm/page_alloc.c | 134,278.47 | +31.67% | > -ritesh