From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qt1-f182.google.com (mail-qt1-f182.google.com [209.85.160.182]) (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 66268431E5D for ; Mon, 20 Jul 2026 18:29:43 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.160.182 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784572184; cv=none; b=J3ML1qrreg9n9fJRMIDAjb7wzxhmRXQXxyeKswZbc7WXBgS1RrNBdyMvkG08NgrQIbAs5rWr+hjP1tAd4qQIbnR8wIBXB0LxpO69S+aopowMqBIVshoE6ExYQZOQfoYpz2S0LVogOb1optzinB4+q1GtUPCo6fEfsAODdYQ3mYQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784572184; c=relaxed/simple; bh=bZ1i/ob8RAwD2ONrC55boLi9X2aDJHrAWwM59fdDkbs=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=UJz4ju/Ur+CTAaL89JSk93YDK6xfnFricsARDfUuXZv5rqYezhHMkD1a1pZo93r2z+GoHyWFuWryPQtjuQdEAp+WLYxmtvfIKIwt8WjfJROVNpQ4e8QQtrdcP9Zigqr01iRsZ8q3KivSMHJ2PuHeGc541eCLy7vRMgRHr79E/WY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=gourry.net; spf=pass smtp.mailfrom=gourry.net; dkim=pass (2048-bit key) header.d=gourry.net header.i=@gourry.net header.b=dMfLvPZK; arc=none smtp.client-ip=209.85.160.182 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=gourry.net Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gourry.net Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gourry.net header.i=@gourry.net header.b="dMfLvPZK" Received: by mail-qt1-f182.google.com with SMTP id d75a77b69052e-51c21495722so74314011cf.3 for ; Mon, 20 Jul 2026 11:29:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gourry.net; s=google; t=1784572182; x=1785176982; darn=vger.kernel.org; h=in-reply-to:content-disposition:content-type:mime-version :references:message-id:subject:cc:to:from:date:from:to:cc:subject :date:message-id:reply-to:content-type; bh=EvlY+ZnuMunvG4k74l6eGWIXWbaZN9lfqhpu+ESLMPs=; b=dMfLvPZKMUsOniq2cwcyq/opEu+HSDAxwBQChpAKcQlUPVw/4NuHbjyh0QgJJd8vjE D3ccl07Su2mUn/7MmcTQhb6XJ8IxK1kWJYMjfyJh4INulwhDARvrL7JcMHBWSxnm/aNf Wl3H9tmskoohpbm4LWpQz6wf+8ICHhhDn+tyRBMh3CPMIXrTJxK3BPd7B+Kxdpja5vKr Wh4HdP88t7lUyXDTCqNThZwan0vxhOGY6wAXGFFDOnp6wiLMxQYG2DW4aovfS0KQQuHh uPUm52nItYOey6fMTFl0To2jYmX9QoRjlK5bYUAE2X2iIiHvidWh2faNs62ckHKUTthx LofQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1784572182; x=1785176982; h=in-reply-to:content-disposition:content-type:mime-version :references:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=EvlY+ZnuMunvG4k74l6eGWIXWbaZN9lfqhpu+ESLMPs=; b=jlzr4SMqlAgKBtMwXHQ69DYXEqAYYSM6DExsHAaMokRQcXtk9rwwxan+zyjq28cxRq gQAzQCTxBE+8Ub0tixd4GpbILUCmi77gmzYjh27+SJ05dZzQdBy95WYW6RQ9AWC3eYup PvGtHZ+09pOXRBtrbyxzViocELnYYdyYkouSLKtW0ylu3q5Ofki9atAoH0j74Dzne2zW 0jR0xjUjPI8fRla7ATVP2KkQv1gbaQR04yffswWl4aexXEdbzsMNdiPY5sD2/Z3ynNaI sOijrq2zi2MLlu8Dvt3KPmwZF27LLyTUTfCRg8Vo/XOIo9+BWqw04vUNEtv29P7CeP8q FUug== X-Forwarded-Encrypted: i=1; AHgh+RojRX7QQOFn2KK6YWxEquoy0T3Uw/0MpdbKPFIK13v7HN/D+UklTjRQlPHMmPgs4qFnCR9CqhnnQqQ56k4=@vger.kernel.org X-Gm-Message-State: AOJu0Yzj71uUuMtHeOaOTrGsWCFjDm1baZyWkyI4PoetK62rU10XqOf8 56oirLm2kSeARG9AqicdzHXbrs1xwHPYowOCF1Y36df+y+5rfM+hPMJTOWf0YVZhZ1I= X-Gm-Gg: AfdE7cnZba8spPBVYcL+MThDupEOYm1TNmLa0nomLuFUWro88SMV/HSW7VVffCuz9Ze 5b1jaDpGyUkwpVSlB//RgXmuUZxUffeNNuWICwQfilizzB1ayZXw2oRIP31W32ZIFOkRMAlIHwh F2hLn+dR5P5bCsmrn/VWFL5UjSTXR0hsb1a4FnXmxQYnlpL6ycBmNKtF+uiYLqL9ekvFl6kxIuZ 5p1aXglIaQJb83oRzpAtKojIctfhB5OC9sFDPZjngmpWe61KmUWHEUzucrf8rqu+e/0VZ4ZgcOy io56VAQWOxFXGVNyZ4ZPav+Hw2yM6lOVgMnUY2UggEOvGTbMbvc/pNE/m2St/lEHrUZpge7sE4S AUbXn6Z5y88r8FpXOLpvrCB6i7D+OTmr4jWX/33HGE7rSTZqVL1YhsW9Xfr3DDUkTd/Wq3Hgnv1 dh3/B1PrfBPhif8lJmB5acblvc36I4DKgqj4nUQWkI2QnfmzL1LOdICYLCsxhvjIBSnjZk X-Received: by 2002:ac8:5714:0:b0:51c:1857:b622 with SMTP id d75a77b69052e-5213e082210mr141591671cf.54.1784572182072; Mon, 20 Jul 2026 11:29:42 -0700 (PDT) Received: from gourry-fedora-PF4VCD3F (pool-173-79-60-52.washdc.fios.verizon.net. [173.79.60.52]) by smtp.gmail.com with ESMTPSA id d75a77b69052e-5214c5cc8d5sm80304611cf.6.2026.07.20.11.29.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 20 Jul 2026 11:29:41 -0700 (PDT) Date: Mon, 20 Jul 2026 14:29:36 -0400 From: Gregory Price To: Matthew Wilcox Cc: Brendan Jackman , Brendan Jackman , Andrew Morton , David Hildenbrand , Lorenzo Stoakes , "Liam R. Howlett" , Vlastimil Babka , Mike Rapoport , Suren Baghdasaryan , Michal Hocko , Johannes Weiner , Zi Yan , Jan Kara , Joshua Hahn , Byungchul Park , Ying Huang , Alistair Popple , Hugh Dickins , Baolin Wang , Chris Li , Kairui Song , Kemeng Shi , Nhat Pham , Baoquan He , Barry Song , Youngjun Park , "Joerg Roedel (AMD)" , Will Deacon , Robin Murphy , Huacai Chen , WANG Xuerui , Thomas Gleixner , Chuck Lever , Jeff Layton , NeilBrown , Olga Kornievskaia , Dai Ngo , Tom Talpey , Trond Myklebust , Anna Schumaker , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman , linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, iommu@lists.linux.dev, loongarch@lists.linux.dev, linux-nfs@vger.kernel.org, netdev@vger.kernel.org Subject: Re: [PATCH 1/3] mm: move internal mempolicy APIs to new internal header Message-ID: References: <20260716-folio-alloc-cleanups-v1-0-5363b8e92d33@google.com> <20260716-folio-alloc-cleanups-v1-1-5363b8e92d33@google.com> 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=us-ascii Content-Disposition: inline In-Reply-To: On Mon, Jul 20, 2026 at 06:52:02PM +0100, Matthew Wilcox wrote: > > > ... With the ulterior motive that I want to add a new parameter to it > > that actually _is_ mm-internal. Namely, alloc_flags, so I can add > > ALLOC_UNMAPPED to implement AS_NO_DIRECT_MAP, i.e. the next iteration of > > [0]. So basically this is > > about trying to extend the allocator without creating a GFP flag. > > Yeah. I'm not sold on the whole alloc_flags thing, but I'm too busy to > sit down and think it through properly to get involved in a proper > argument about how it should work. > > My entirely unresearched and ill-considered opinion is that the __GFP > flags should _be_ the ALLOC flags. We shoudn't be translating GFP flags > into ALLOC flags that are what the allocator actually uses, the > translation should be done at compile time. So if GFP_KERNEL and > GFP_ATOMIC need to be composed of different flags with different > semantics, then we should do that, not invent a different set of flags > that special people can use for special purposes. > alloc_flags is putting me between a rock and a hard place. I figured out a clean isolation mechanism with zonelists (new rfc is posting today, i'm doing one last proofread), but it required me to extend some of the mm/ internal interfaces with a zonelist selector. Since Brendan's base work made it in mm-new, i decided to replace the zonelist selector with ALLOC_ZONELIST_PRIVATE as the selector to avoid *yet more* arguments. I'll be posting with ALLOC_ZONELIST_PRIVATE on top of mm-new, but the churn is getting painful. It really seems like we just want an mm/ internal interface that exposes struct alloc_context for specific *mm/* callers (see: compaction_context, migration_context, etc), and interfaces that keep this nonsense transparent for everyone else. Then if you want access to alloc_context interface, you need to get export approval for that component (similar to EXPORT_FOR_MODULES). Just spitballing here, but the churn is killing me. ~Gregory