From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f45.google.com (mail-wm1-f45.google.com [209.85.128.45]) (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 128A83B8959 for ; Tue, 2 Jun 2026 08:57:53 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.45 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780390677; cv=none; b=QIhI24UmN1QQNVM9QHTmd98WJN0sq784+YszoFolbwmZMTrD8GAotDcg9B/STohm1lMMR2IMsESNkR57vweziRNr4ZTB8+JzzjkexG/GMPKXV9OLmPHgstatNZFoGlI9yb2HPFUVJvC3GI9ZCXTpB/duq9Zb/LD+hUK4WxEr7fw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780390677; c=relaxed/simple; bh=02DEH1RNeabzh34kxStDmLoX6DGXErAolWL5BXl6jBY=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=qwoSRr615TZV38kw393DzQUyCr50r06y9Gw5x4A5C3DXgudUH/j3iEALgNvMSJ2WygkYSFDRlB7nbqJeEw6Hm+Y7WgHceWVoE+YDVVmr4yJLvjjeLj21wCryvvvyut0ancCavcB/YM53HOMpqOkII2FoKTLT5LV0nLiSORpjH9M= 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=gU1ml9NI; arc=none smtp.client-ip=209.85.128.45 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="gU1ml9NI" Received: by mail-wm1-f45.google.com with SMTP id 5b1f17b1804b1-490a76757e5so17077795e9.2 for ; Tue, 02 Jun 2026 01:57:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gourry.net; s=google; t=1780390672; x=1780995472; 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=/m/AOq0MzWCa7qNuImbU6Sf3NfKogr80Anbl3dKp5VQ=; b=gU1ml9NISOhcy+km3kg+NwiZgFqta5GJX8mUC/fZ7NINj6JHkjnsIas4HTPzOQI+J+ t5ALTwEQfB1xKxLnG4QvfzY8jQX7A3JGGcLex91Ha1VpAe48Fmt0w7mTcDxZzHxY2sXr VAITYpjTuotJx7ZxDDGKc9mS7mCLj/rDUnS8IWvjcpZ+yxuLhUUdJ2zUgQ8NkFG8C57Y B+Ih4bQBn1G7Rkvcv0Mko3TYQV41em9n2TK4cKaaFlORSnx138FKX3RaSlSh2ciLnFk9 TmvPGqGaiXa4RSgzOMLFsZ7KqSKp/xi16XRTXNfl26OHk4rV8G9EiGk5PTAU6+1vxsx2 imzA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1780390672; x=1780995472; 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=/m/AOq0MzWCa7qNuImbU6Sf3NfKogr80Anbl3dKp5VQ=; b=Xf/wx7KjxLA3f9FxZuCe5Y2X9C1k72yHVillljcoOWg1oT5q+X/top6JwlryREYOFQ 0ByGYtRgesU01tAr5B5gcD2B/7sLwygW/3eLZFiIJCDxF1DNOgYBSXFWS2XHQ2aKBYyw R7MOIWjRLKwPHhnVYJq70xZ8IPkNAYpLiRRCd+tME+njT54oWxLmxi876nthRQu+P51/ 8KD4TZm3M8ulEhTSe4ocG+Kys+cwtzPz2zShoCIdmsu0FeheO8bQaoIMkLgku7CnNnUT WvLyMlHJxgYzhrShVTuWfvO13ZHvphD2VFMjidYhapPIeYlUxps/HXRE/jSGX4uNvWFj if3A== X-Forwarded-Encrypted: i=1; AFNElJ8X0CFBFfEw1OEQlPxS4uSNlB1U4QgrX+9reE7HGYwcUMDwxb3rpBRBNo6in5AUwG7t9D7NMOZI/WuS1jI=@vger.kernel.org X-Gm-Message-State: AOJu0YwImP6cVWELW+MNyMqOmdVgaVDKqz4BcweHuePbGKKB8VSykg3j yN+aOk3yH6+q+ZaRqxXkbPFL+fDs9V7zY6pnwhXsvhiYjwXboTnq5ZXY6e0XrnAOGFY= X-Gm-Gg: Acq92OGbDrJCYztS5qpmq0UmCmO4kJntHWTxJFV3z/aMhhWbzO1VkMBE0bkfvbVCmi3 udBmXlHaqiicgK3TJPwnRVwfFnkEVR8P2gwuV+rF8jj/syi9ZGuaA0F5/qdH66HM0com9E0w+gC T084NuC/2PRXgtZ5ON1jUnK5xThCkL9/do6XF0muRJXFDEl/1UeJvYeWm8Q/qov7YAtV+ayApQ5 wkywocSslAtP/z0v1mHszhLYuegNk3wpVfgY2jPToHzEVMQlVGT1sLn2zwWOxlWm2q9r/3Pc5uR xBGpxtBWUZxicbhYW1notCb/EKFN+VR3miTR0g6YnQa4zVkL28nKn4TqqZEYmKN9tRLfTI4VtmI DJHQm4FdtNEjinzXhZ0RHH4BB0UgXg2w39RL0NbfRGTBTkJUexV3zu6dffCZ/rbvio8TaAB3yrA FtCCFxgZlxgIRW/vnQ52Ypnp4rpAtZmH+IYjhjdt1CNQ== X-Received: by 2002:a05:600c:a009:b0:490:ad8e:11bc with SMTP id 5b1f17b1804b1-490ad8e1279mr109459155e9.31.1780390672385; Tue, 02 Jun 2026 01:57:52 -0700 (PDT) Received: from gourry-fedora-PF4VCD3F ([2620:10d:c092:500::6:6dc9]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-45ef354c682sm30647541f8f.23.2026.06.02.01.57.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 02 Jun 2026 01:57:51 -0700 (PDT) Date: Tue, 2 Jun 2026 09:57:48 +0100 From: Gregory Price To: Balbir Singh Cc: 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, david@kernel.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 Tue, Jun 02, 2026 at 12:16:50PM +1000, Balbir Singh wrote: > On Sun, May 24, 2026 at 09:50:06PM -0400, Gregory Price wrote: > > > > I'm debating on whether to include OPS_MEMPOLICY in the initial version > > if only because it's not intuitive how it interacts with pagecache. That > > needs more time to bake. > > > > It makes sense to look at it and then decide if it makes sense. > I am thinking i will ship without any OPS flags at all for now and the have the introduction of ops as a separate series. > > alloc_pages_node() is the kernel interface > > I was think we wouldn't need explicit flags and that allocations would > happen from user space using __GFP_THISNODE to the node or via a nodemask > based on nodes of interest. Is there a reason to add this flag, a system > might have more than one source of N_MEMORY_PRIVATE? > There's a few things to unpack here. I discussed this many times on list and at LSF, but to reiterate. 1) __GFP_THISNODE is insufficient to enforce isolation and otherwise not particularly useful. Additionally, from userland, it's not something you can actually set. for node in possible_nodes: alloc_pages_node(private_node, __GFP_THISNODE) In fact it's the opposite semantic of what we want. THISNODE says: "Do not fallback back to OTHER nodes". The semantic we want is "Do not allow allocations from private nodes UNLESS we specifically request" (__GFP_PRIVATE). __GFP_THISNODE does not actually buy you anything here, AND it's worse, in the scenario where a private node makes its way into the preferred slot (via possible_nodes or some other nodemask), the allocator cannot fall back to a node it can access. __GFP_THISNODE cannot be overloaded to do anything useful here. 2) We're trying not to expose *ANY* userland APIs for this, at all. The ultimate goal here should be one of two things: 1) fd = open(/dev/xxx, ...); mem = mmap(fd, ...); mem[0] = 0xDEADBEEF; /* Fault device page into page table */ In this case, the driver is responsible for doing the alloc_pages_node() call. or 2) mem = mmap(NULL, ..., ANON); mbind(mem, ..., private_node); mem[0] = 0xDEADBEEF; /* Fault device page into page table */ in this case mempolicy.c is responsible for doing the alloc_pages_node() call via the _mpol() alloc variants. Addition OPT flags (reclaim, compaction, whatever), would (optionally) allow mm/ to operate on the device memory with, for example, mmu_notifier callbacks to tell the device to invalidate whatever it's caching about that page. This would all be relatively transparent the userland, all userland "knows" is that it's getting memory from a device (/dev/xxx) or a node it's otherwise aware of hosting device memory somehow. ~Gregory