From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C588E44A730 for ; Tue, 16 Jun 2026 15:23:26 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781623408; cv=none; b=gUj4j9TxxrRqNCy/XO73ILAwcOAg6n7UaJvqbK+S86zVKGHsCIWKxnWVru4OrdIwf252B9G4qQXYDOg9puxv/UXd7D987dvQIPvn2fvnu9qCxCLPUXDzGT258EZ+dfRNq03p5CLpCL9+Xc0d/WANanv9UXSI2RtQUORXdNUOghk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781623408; c=relaxed/simple; bh=8i4twbSNDv02zgD1VY8jsEZ9u0TWwzEkJYMF1EplDoo=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=CEHxh0hpL+fnPJMrS3HY47uIl97T/gdzFrWWijFF202b0HP+0svyqQ+tSzauxEoYvGG4RPrnPAZM+X+7WmSXEqF+rAVr+25VMGxk74mZtcM4PsEPa04AhC0gzWGiD+Lm7PR1tC5pp5iMonaex+su+t2YPBraYsJIbGr6S0Lfnj4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=geo5TEql; arc=none smtp.client-ip=170.10.133.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="geo5TEql" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1781623405; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=r1AASZfTRVbzLt5I/0GBJdZ/bjP6ci4PfAYJuRBn4WE=; b=geo5TEqlyyZzeaZsqG2drVdY8is8kdZdFwqdK7SJ+PX9773gwcciGq5tkIbJuuXyDKiXiI m/IkqPXHvgpDIA13+ZGhrQ5aYWjdYQH7EjaESb1+Ei5CyLlDSUVdMNjcsd/DXxhBJZ7XYF AZ60IShdu620b/O/eRSWtUaz0okwAvI= Received: from mx-prod-mc-03.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-362-YOZ8QqoZNdCi67PK60bP_g-1; Tue, 16 Jun 2026 11:23:22 -0400 X-MC-Unique: YOZ8QqoZNdCi67PK60bP_g-1 X-Mimecast-MFC-AGG-ID: YOZ8QqoZNdCi67PK60bP_g_1781623400 Received: from mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.93]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-03.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 42A251954B17; Tue, 16 Jun 2026 15:23:19 +0000 (UTC) Received: from [10.22.81.159] (unknown [10.22.81.159]) by mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 12209180059C; Tue, 16 Jun 2026 15:23:14 +0000 (UTC) Message-ID: Date: Tue, 16 Jun 2026 11:23:14 -0400 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] cgroup/cpuset: rebind mm mempolicy to effective_mems, not mems_allowed To: "David Hildenbrand (Arm)" , Gregory Price Cc: Farhad Alemi , Andrew Morton , Farhad Alemi , Yury Norov , Joshua Hahn , Zi Yan , Matthew Brost , Rakie Kim , Byungchul Park , Ying Huang , Alistair Popple , Rasmus Villemoes , linux-mm@kvack.org, linux-kernel@vger.kernel.org, cgroups@vger.kernel.org, stable@vger.kernel.org References: <8d3b4561-92cd-4ebc-8462-5fb0fd659e8a@kernel.org> <70f486ce-5ef6-4d72-8cc3-7086f4eea930@redhat.com> <51eafe6c-6622-479b-b391-6d3ff9350e75@kernel.org> Content-Language: en-US From: Waiman Long In-Reply-To: <51eafe6c-6622-479b-b391-6d3ff9350e75@kernel.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.93 On 6/16/26 2:59 AM, David Hildenbrand (Arm) wrote: > On 6/16/26 05:43, Waiman Long wrote: >> On 6/15/26 10:26 PM, Waiman Long wrote: >>> On 6/15/26 5:38 AM, Gregory Price wrote: >>>> All interactions between mempolicy and cpuset are horrible and >>>> confusing.  Much like Lorenzo's anon_vma work, I have to keep >>>> notes on how this whole thing doesn't just spew SIGBUS constantly. >>>> >>>> The short answer is: mempolicy is advisory and cpuset is strictly >>>> followed - in a dispute cpuset wins... except for file backed memory, >>>> then everyon loses and nothing is consistent. >>> That is what I believe why mpol_rebind_mm() a bit differently from the others >>> and it is historically done this way a long time ago before cgroup v2. >>> >>> For cgroup v1, mems_allowed can't be empty or you can't put any task into the >>> cpuset. Also effective_mems is the same as mems_allowed. cgroup v2 is quite >>> different in how it handles memory nodes and CPUs. Users can isn't forced to >>> set mems_allowed and cpus_allowed as effective_mems and effective_cpus will >>> inherit parent version if mems_allowed and cpus_allowed are not set. IOW, >>> effective_mems will never be empty. Yes, it is a bug with the introduction of >>> cpuset v2 that we should have replaced mems_allowed by effective_mems at that >>> time. With v2, effective_mems should contain only online nodes. The only >>> exception is during the short transition period when a memory node hotunplug >>> operation is in progress when a write to cpuset.mems is happening at the same >>> time. With v1, it is theoretically possible that none of the nodes in >>> mems_allowed is online. >>> >>> The reason why I am suggesting to use cs->effective_mems to keep the old >>> cgroup v1 behavior. If the consensus is to use the output of >>> guarantee_online_mems() for mpol_rebind_mm(), I will not be against that but >>> it will be a slight change in user-visible behavior. >> BTW, I still prefer the v2 patch. If it is decided we should use the >> guarantee_online_mems() value instead, it will have to be a separate patch with >> changes in the relevant documentation like Documentation/admin-guide/cgroup-v1/ >> cpuset.rst. > newmems is "obviously" correct, so I really don't see why we should add > something that needs half a page of text to explain why it is fine -- if newmems > just does the trick? > > Please enlighten me. Yes, taking newmems is a reasonable choice and there are pros and cons with each options. My focus is more on not changing how v1 cpuset behaves as it is well defined in the v1 cpusets.rst file:     Requests by a task, using the sched_setaffinity(2) system call to     include CPUs in its CPU affinity mask, and using the mbind(2) and     set_mempolicy(2) system calls to include Memory Nodes in its memory     policy, are both filtered through that task's cpuset, filtering out any     CPUs or Memory Nodes not in that cpuset.  The scheduler will not     schedule a task on a CPU that is not allowed in its cpus_allowed     vector, and the kernel page allocator will not allocate a page on a     node that is not allowed in the requesting task's mems_allowed vector. v2, OTOH, is more vague as to what setting cpuset.mems will mean and we generally follow what v1 is doing, but we have more leeway of what we can do. Using newmems will make the above text not totally correct. At least the offline memory nodes will be filtered out which will not be utilized by the task when the offline node becomes online. That is why I am saying that we will have to correct the documentation if we want to make this change. Cheers, Longman