From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qk1-f177.google.com (mail-qk1-f177.google.com [209.85.222.177]) (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 79F5C2D24B7 for ; Wed, 10 Jun 2026 22:18:13 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.222.177 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781129894; cv=none; b=dJOkBSaaBKBsbvP3LW2Nw/dexxP+NvjFaVYufg6SEMFqFmRh3/OYacdFRTMmKIA5/pYLfXanGSsJez+1OwuBCTpuUskJu74uZHkWFsw8oxETAqls3Ae0K8TGH62GC16sysjN8XO44bMmhwH8EGgat1soZZlg6TfsNoJOReBNov0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781129894; c=relaxed/simple; bh=n6qQe/H8M9f/HunhZcM7AZ4l6+kkk/hPRfn60YC5VlI=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=L/KlT7JkrJ4+Lb400a4SwVAahi3zZMllcE+3UHyq3oPN6fqjH57wsQ8R/NM5pqbkT1GFkQPpPPDS/bkPQsv0MsUpmBSWJK9qOCW5PsplVDcDXvlBVcgOlMBzyd4NKR7N4AW5P0WfViZJsZAhAyTYWkPZYGgQVXZH0/9wHRr34mI= 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=V3vKIxUP; arc=none smtp.client-ip=209.85.222.177 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="V3vKIxUP" Received: by mail-qk1-f177.google.com with SMTP id af79cd13be357-9156b74006aso527356485a.0 for ; Wed, 10 Jun 2026 15:18:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gourry.net; s=google; t=1781129892; x=1781734692; darn=vger.kernel.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=j1PbvrJxmu0Zl4ziOeo1RdvYlevUlgdJVEfHD2noTRQ=; b=V3vKIxUP2xQMBPVbbKnJ/vNJOjqfa2Eji6/VFzoKcer3eo+JRBwicBO8NaCpEb08y2 RAW7SmKqHygNl72UBObn4fn/nuHkqdvWW1dKPuzdEEcSWboJZ5JOS9WVn/D9sNIg/tOf 2MvqrjyXRommi696jqaFRJYj57UZOi+5XcribHaAg/43qvEuApqTYAAiwTwkZOBPC6dn azP5IvkGkft42VwkW5Ue835DqIj+UpvZhdoEWGrva6lq7YNvgd1YOkj7nqGrhJD/RDQz ywkCPP7sMepNhKf6jDO9ZFAb4HbaENWNB7AynuXgZJKT350BEJFmUbrNeKR/o2IAMVh4 Xwxw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1781129892; x=1781734692; h=in-reply-to:content-disposition: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; bh=j1PbvrJxmu0Zl4ziOeo1RdvYlevUlgdJVEfHD2noTRQ=; b=SdgZIsHat0s75+KSkxJmiC3DiekmjPGHt+OM2CPvgjr4LDwCECvjsU8m9hwflnkV6T myg0u6CadAfkBDSNqb6K9lRbbBjBc7xtANxgZBIDJIr6LGUNNDG+C10a7bDZku5BOffw kVcisWxZT5STcrxFbcqrxjc7VX9oZycpwgNrUzyAI6+vScwOJs1fu7I43u0w3CFwaNV6 SSxc4FYIOofERpgIitaAgMf27o1kF6zQOcnLkXlT+2MB2silEVQTvJsq/FDMOrzI8G4G tNoH7nHLtPectgSzHNSpA1ihOOsoOuv0hYY06PcFMwHruZJmx2spn/0rDELCqy6T/Upj x4Gg== X-Forwarded-Encrypted: i=1; AFNElJ+5hbF7Y9g35ASS6trxaNi0kAjLUTIfrhLXCr4585hnkHZ7nze9ksbRDhbpEu45yI05jGslX98CkzD4w6A=@vger.kernel.org X-Gm-Message-State: AOJu0YyGohh3uYOFrbRslkqFse+/fspLwkyeDbJB43nS0TfNA4B+viKC e1vLt42elW1KY8EnbnlW2qD3kgRbhPn25WlnbwChUbeTrsfoHjc8Dh+39uK//TrMVL4= X-Gm-Gg: Acq92OGxqkuX3aRGKIWExpc86P7yim0rZEzP9uv7+rlYfxliXAevrBeJyp8sZRa+P9Q Dl8KxJRvAM2jHXwWplH/guV6mvaa0TGT8zv0oNDn3n9WzE9syxp+GZtR9nbLqXg5arOoSv5F+A6 h957A5HHidk0UlNOLRB2MliIDB39ZNq6xK/VzEjD/ootctJdsYqvDSUgyhp+JIplr53uXMSWjTs drT0dk6BhfPDNT6o9t3npKX7KjbpyJ8AIrQxRZdze6hT2fmwBvO2aPZ3eLL18PWsiISBvSx9J+I kDhktTT39If/dFWkPga5HpcI+I4Lk+w7PEZtjJYoNM7aUgQLEQSScK5LQk3HIukOuoK93SS36jz nOQt+bJ3Mg6QhURr169v38MD7ZQ3jd3N5ho4MFSsGSCzTvUQpn5x3HvVDPM8No57O65SC/k9fka rwU+ylaxTiEJlcTbVfCFoAZNrfaCEz2NKlRoD9RtzLAhXtXU9LgTXvip17bpo1faEWh/qR8ioRG 36srsq44Nmxs8leTw== X-Received: by 2002:a05:620a:2993:b0:8f1:5e8f:fff3 with SMTP id af79cd13be357-915a9cc266bmr4381110385a.26.1781129892358; Wed, 10 Jun 2026 15:18:12 -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 af79cd13be357-9158a243041sm2641676685a.18.2026.06.10.15.18.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 10 Jun 2026 15:18:11 -0700 (PDT) Date: Wed, 10 Jun 2026 18:18:08 -0400 From: Gregory Price To: "David Hildenbrand (Arm)" Cc: Balbir Singh , lsf-pc@lists.linux-foundation.org, linux-kernel@vger.kernel.org, linux-cxl@vger.kernel.org, cgroups@vger.kernel.org, linux-mm@kvack.org, linux-trace-kernel@vger.kernel.org, damon@lists.linux.dev, kernel-team@meta.com, gregkh@linuxfoundation.org, rafael@kernel.org, dakr@kernel.org, dave@stgolabs.net, jonathan.cameron@huawei.com, dave.jiang@intel.com, alison.schofield@intel.com, vishal.l.verma@intel.com, ira.weiny@intel.com, dan.j.williams@intel.com, longman@redhat.com, akpm@linux-foundation.org, lorenzo.stoakes@oracle.com, Liam.Howlett@oracle.com, vbabka@suse.cz, rppt@kernel.org, surenb@google.com, mhocko@suse.com, osalvador@suse.de, ziy@nvidia.com, matthew.brost@intel.com, joshua.hahnjy@gmail.com, rakie.kim@sk.com, byungchul@sk.com, ying.huang@linux.alibaba.com, apopple@nvidia.com, axelrasmussen@google.com, yuanchu@google.com, weixugc@google.com, yury.norov@gmail.com, linux@rasmusvillemoes.dk, mhiramat@kernel.org, mathieu.desnoyers@efficios.com, tj@kernel.org, hannes@cmpxchg.org, mkoutny@suse.com, jackmanb@google.com, sj@kernel.org, baolin.wang@linux.alibaba.com, npache@redhat.com, ryan.roberts@arm.com, dev.jain@arm.com, baohua@kernel.org, lance.yang@linux.dev, muchun.song@linux.dev, xu.xin16@zte.com.cn, chengming.zhou@linux.dev, jannh@google.com, linmiaohe@huawei.com, nao.horiguchi@gmail.com, pfalcato@suse.de, rientjes@google.com, shakeel.butt@linux.dev, riel@surriel.com, harry.yoo@oracle.com, cl@gentwo.org, roman.gushchin@linux.dev, chrisl@kernel.org, kasong@tencent.com, shikemeng@huaweicloud.com, nphamcs@gmail.com, bhe@redhat.com, zhengqi.arch@bytedance.com, terry.bowman@amd.com Subject: Re: [LSF/MM/BPF TOPIC][RFC PATCH v4 00/27] Private Memory Nodes (w/ Compressed RAM) Message-ID: References: <20260222084842.1824063-1-gourry@gourry.net> 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 Wed, Jun 10, 2026 at 08:59:59PM +0200, David Hildenbrand (Arm) wrote: > > At LSF/MM we talked about how GFP flags are bad and how deriving stuff from the > context might be better. I think there was also talk about how the memalloc_* > interface might be a better way forward. Maybe we would start giving the > allocator more context ("we are allocating a folio"). > > The following is incomplete (esp. hugetlb stuff I assume), just as some idea: > Ok, this was easier to test than I expected, and hugetlb is indeed a stickler. We can't get there 100% with just MEMALLOC_FOLIO, we still need a MEMALLOC_PRIVATE - specifically because of users like hugetlb. hugetlb uses __GFP_THISNODE to do its allocations, and all hugetlb allocations are folio allocations - so the code you shared by itself does not gate hugetlb from spilling into private nodes. That means we still need something like this in hugetlb: if (node_is_private(nid)) /* fail allocation */ HOWEVER... if you have MEMALLOC_PRIVATE - you make the allocation failure a *page allocator* problem, and it serves exactly the same purpose that __GFP_PRIVATE did. the resulting code is two lines in my anondax driver: unsigned int priv_flags = memalloc_private_save(); ret = do_anonymous_page_node(vmf, dev_dax->target_node); memalloc_private_restore(priv_flags); No special hugetlb, slab, arch code handling - they all just fail to allocate / fall back. If they fail - it means that code is using a bad nodemask and we need to go fix it (exactly what we want!) I think additionally, we might be able to repurpose MEMALLOC_PRIVATE flag for Brendan's needs as well [1]. Their goal (IIRC) was to have a pile of unmapped blocks that could be opportunistically converted to normal memory, but otherwise left unmapped and sitting in the buddy. Same thing - different filter point (blocks vs nodes). If you set MEMALLOC_PRIVATE - it makes private node allocations possible, and "private block" access (without conversion) possible. Otherwise private nodes are unreachable, and private blocks would be treated like CMA (last-resort stealing, lazy-direct-mapping). And they stack (private blocks on private nodes :V). I don't have enough time looking at his proposal, but it seems like we can kill two birds with one stone on this. [1] https://lore.kernel.org/linux-mm/agYJcRgOHho8upVv@gourry-fedora-PF4VCD3F/ ~Gregory