From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qk1-f193.google.com (mail-qk1-f193.google.com [209.85.222.193]) (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 CBF182F49F8 for ; Mon, 12 Jan 2026 15:26:20 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.222.193 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768231584; cv=none; b=tOrvCprhbW8Qs2ml5rYmH4d0PkpipOelqu+gvCpOKMNMrgf7SyG/DBp+PXsOvIzV3CYAiRql6UF+zKbeXIe2JLJNWC42HSD9KC0a/0ANzQjyJLKDwnlSnMtdiG/WlZFCByCMTjsfID9yzTcp4eT0kuvZp40OMqAXJ8KDU0ih2/o= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768231584; c=relaxed/simple; bh=EULRbDh2eWrxKTzxeqVj7dyOdGXNsrU4bT7mvwNID8s=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=DJyTr69OOOfwKQaxOXyDeqH71bTatDlDYMVCeFD0Q+YPFS+PqxMJLweCQvGcrHChBzsmATr6M4T8rtcYQEOcZeAukvntZZK+llSVDmxf6gTXhImYCKwIGNU3il8+TghBmNZqeh+6Fv007c7u2ZS1eenuBwbWAv8hUaFOI+Fscuk= 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=IYbYov2W; arc=none smtp.client-ip=209.85.222.193 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="IYbYov2W" Received: by mail-qk1-f193.google.com with SMTP id af79cd13be357-8b25ed53fcbso128844085a.0 for ; Mon, 12 Jan 2026 07:26:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gourry.net; s=google; t=1768231579; x=1768836379; darn=vger.kernel.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=57UuhljdncFCr/JytocOWEZRWmlPR6Nv3ccaWVm2VXI=; b=IYbYov2W9czkLWI6VyMzlenE6G8F92zW/RL6fC79g8xfvBcwtysPEjGuxKdft9iGWt tPc4NFzIep1NbXA3rC5KnCqzwbz93sfzLwFimFf82zEBPuJDW18oNGlnG11+SJylEfha ek8hwl2288dHGcvZQIiwTGuuVJnrRzLfXZBOS/OOpkGQc/EwI+slj+Crm9PdFvSEGJ+W IhdbfwBt2T/r+E7mMyvlfXrbedq+H6dIzsQDT2yfCXXvUdpVtZbg1VzBt4o8bUJ/YCZ4 vlHA+WkSbs6rb0PYrAJRtA7JepyDZCMgLLek3WRknkhaGnE5n5XC+PTwfc96/ckeR0lS 4F+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768231579; x=1768836379; h=in-reply-to:content-transfer-encoding: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=57UuhljdncFCr/JytocOWEZRWmlPR6Nv3ccaWVm2VXI=; b=tLv+JrPpSMqrbOlCeeVGdlCU/FNeUQo+EdjNiAlCHovvQaNuRtCgeI8rDIAwBOBdft SMXGlHO/DftI8CGzdnN8lnmmrCl7quOYdS+IFodVD4sLwCNeOLutiL9jDUryN+Q8m5je Ff37zuszWtyUjoO5QM5S4QtbbAZrq2GYWu3H4AUSU5dWs0YtdTn/eZp67a0iZmzNFPbC 1tjMzZXOF5sHwTzabmkw1NpGusWA/BvHUMbQhSSZ6cEWjVkhWu2QhR6bNVHWdI5CrF64 ps2N2lREAu3Cwhk2EMw9FdiUEeoAkRY6qyLO9vPqmg4cPt/M9vNdCEjT++LZ671T+2RH or7A== X-Forwarded-Encrypted: i=1; AJvYcCXe4f1Fsi6nn67kZ/RkeZvGfjUHvZLB0ZXnoRlnVj2WeGpqn4/Sg/d9K6NJ5lP1EP5GAS4VHyOtpyPBM1A=@vger.kernel.org X-Gm-Message-State: AOJu0YwjNciC5TwE35m3i9h4cQAVRgCYRFGdmL2VkKHzzPyWhK5oCXSB qLNgPaw/HeAoHYKu9UWgQ/lwoCdga5Cj8J5qQsyFO/0ENbvGQlQeQItlcUUA1emxxvg= X-Gm-Gg: AY/fxX7rLpAWIwkcdKcXnDkjIksBHL2dRwsRRkB62jR9IKLrvHkSn+2uMe0NC9OjIuJ ysE0/m2g9ug2GHyZDPCoJ23yjy0+tFwMmEhwU3pTBQlCRGlG92Gsc41HsehCaz/DdqYqwaQby2/ WO61RqxxpdK9GhNpFYiZ2HMWfmXPjX5LpoWAadEHqNlz5eKT635igZJyIHRNEiG5XBFy64WaLHO XICNHHuYc8PCi7O1ZJzbOepr9lXkJRGPdHaAq3un4j0c7V8sNHJOg7kuK50/XbkIcYM183PYi0a Lf5hE+xEFZF6vYKNeB5Yj2uMlFkiJX7AT7qOlCV8D8AUUT69E+o65m4iURVJ5Ni2fllIh/qdlRI DzjOdln+ZgAquNiNC6pZyQRy6Tc1RQxa4BiMNxM0Xq2AOOlYV+tmFRBZkThmclNR0z2yRbKOE5Z O6vW4NTGtVryXlSzHOYKsgOIL3SVquheoo3sXdedBBw/JYOT4mfVMcgOnXpPMV3PUhvP8gnGo49 SjRbEO/ X-Google-Smtp-Source: AGHT+IF7YU4wyH5DCnIa1xHNwfOTUxRN3Z3UmWPqqY8/JzoeuGL9L4VducxuPGVH8SICTsnA4+h6Uw== X-Received: by 2002:a05:620a:318a:b0:8b4:ebbe:ae04 with SMTP id af79cd13be357-8c3893a5c0bmr2745515485a.35.1768231579175; Mon, 12 Jan 2026 07:26:19 -0800 (PST) Received: from gourry-fedora-PF4VCD3F (pool-96-255-20-138.washdc.ftas.verizon.net. [96.255.20.138]) by smtp.gmail.com with ESMTPSA id af79cd13be357-8c37f5439cbsm1508794985a.55.2026.01.12.07.26.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 12 Jan 2026 07:26:18 -0800 (PST) Date: Mon, 12 Jan 2026 10:25:44 -0500 From: Gregory Price To: Michal =?iso-8859-1?Q?Koutn=FD?= Cc: linux-mm@kvack.org, cgroups@vger.kernel.org, linux-cxl@vger.kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, kernel-team@meta.com, longman@redhat.com, tj@kernel.org, hannes@cmpxchg.org, corbet@lwn.net, 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, akpm@linux-foundation.org, vbabka@suse.cz, surenb@google.com, mhocko@suse.com, jackmanb@google.com, ziy@nvidia.com, david@kernel.org, lorenzo.stoakes@oracle.com, Liam.Howlett@oracle.com, rppt@kernel.org, axelrasmussen@google.com, yuanchu@google.com, weixugc@google.com, yury.norov@gmail.com, linux@rasmusvillemoes.dk, rientjes@google.com, shakeel.butt@linux.dev, chrisl@kernel.org, kasong@tencent.com, shikemeng@huaweicloud.com, nphamcs@gmail.com, bhe@redhat.com, baohua@kernel.org, yosry.ahmed@linux.dev, chengming.zhou@linux.dev, roman.gushchin@linux.dev, muchun.song@linux.dev, osalvador@suse.de, matthew.brost@intel.com, joshua.hahnjy@gmail.com, rakie.kim@sk.com, byungchul@sk.com, ying.huang@linux.alibaba.com, apopple@nvidia.com, cl@gentwo.org, harry.yoo@oracle.com, zhengqi.arch@bytedance.com Subject: Re: [RFC PATCH v3 5/8] Documentation/admin-guide/cgroups: update docs for mems_allowed Message-ID: References: <20260108203755.1163107-1-gourry@gourry.net> <20260108203755.1163107-6-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=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On Mon, Jan 12, 2026 at 03:30:26PM +0100, Michal Koutný wrote: > Hello. > > On Thu, Jan 08, 2026 at 03:37:52PM -0500, Gregory Price wrote: > > --- a/Documentation/admin-guide/cgroup-v2.rst > > +++ b/Documentation/admin-guide/cgroup-v2.rst > > @@ -2530,8 +2530,11 @@ Cpuset Interface Files > > cpuset-enabled cgroups. > > > > It lists the onlined memory nodes that are actually granted to > > - this cgroup by its parent. These memory nodes are allowed to > > - be used by tasks within the current cgroup. > > + this cgroup by its parent. This includes both regular SystemRAM > > + nodes (N_MEMORY) and Private Nodes (N_PRIVATE) that provide > > + device-specific memory not intended for general consumption. > > + Tasks within this cgroup may access Private Nodes using explicit > > + __GFP_THISNODE allocations if the node is in this mask. > > Notice that these files are exposed for userspace. Hence I'm not sure > they'd be able to ask for allocations like this (or even need to know > about this implementation detail). > Fair, I can drop this, the intent is actually to limit user-space knowledge of this at all. > > > > If "cpuset.mems" is empty, it shows all the memory nodes from the > > parent cgroup that will be available to be used by this cgroup. > > @@ -2541,6 +2544,25 @@ Cpuset Interface Files > > > > Its value will be affected by memory nodes hotplug events. > > > > + cpuset.mems.sysram > > + A read-only multiple values file which exists on all > > + cpuset-enabled cgroups. > > + > > + It lists the SystemRAM nodes (N_MEMORY) that are available for > > + general memory allocation by tasks within this cgroup. This is > > + a subset of "cpuset.mems.effective" that excludes Private Nodes. > > + > > + Normal page allocations are restricted to nodes in this mask. > > + The kernel page allocator, slab allocator, and compaction only > > + consider SystemRAM nodes when allocating memory for tasks. > > + > > + Private Nodes are excluded from this mask because their memory > > + is managed by device drivers for specific purposes (e.g., CXL > > + compressed memory, accelerator memory) and should not be used > > + for general allocations. > > So I wonder whether the N_PRIVATE nodes should be included in > cpuset.mems[.effective] at all. I think it makes the control path easier (both more intuitive and easier to write in the cpuset code), but I can take another look at this. Although omitting them from .effective i think prevents the user from controlling whether their memory ends up on that node. i.e. the user might be aware that they have compressed memory on node N, and they have a cgroup that they don't want on node N - not having it included in mems.allowed / mems.effective means they can't control this. > (It resembles CPU isolation to me a bit ~ cpuset.cpus.isolated.) > Maybe you only want to expose it on the root cpuset cg and inverted like > cpuset.mems.private? > Hm, I had not considered adding the separate mask for .private as opposed to sysram. If all we actually need to change is the allowed() callback to check an additional nodemask, that might end up cleaner. Thank you, I'll take another look at this piece. ~Gregory