Message-ID: <a9ef4da9-828e-2370-08ed-91bbd8b8e4e5@redhat.com>
Date:   Sun, 5 Feb 2023 11:34:50 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.6.0
Subject: Re: [PATCH v2 2/2] cgroup/cpuset: Don't update tasks' cpumasks for
 cpu offline events
Content-Language: en-US
From:   Waiman Long <longman@redhat.com>
To:     Peter Zijlstra <peterz@infradead.org>
Cc:     Tejun Heo <tj@kernel.org>, Zefan Li <lizefan.x@bytedance.com>,
        Johannes Weiner <hannes@cmpxchg.org>,
        Will Deacon <will@kernel.org>, linux-kernel@vger.kernel.org,
        cgroups@vger.kernel.org, kernel-team@android.com
References: <20230202143200.128753-1-longman@redhat.com>
 <20230202143200.128753-3-longman@redhat.com>
 <Y94oDD/8PDGqNLTH@hirez.programming.kicks-ass.net>
 <68d7c246-a678-df0c-6f54-d69725a085cc@redhat.com>
In-Reply-To: <68d7c246-a678-df0c-6f54-d69725a085cc@redhat.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 2/4/23 23:40, Waiman Long wrote:
>
> On 2/4/23 04:40, Peter Zijlstra wrote:
>> On Thu, Feb 02, 2023 at 09:32:00AM -0500, Waiman Long wrote:
>>> It is a known issue that when a task is in a non-root v1 cpuset, a cpu
>>> offline event will cause that cpu to be lost from the task's cpumask
>>> permanently as the cpuset's cpus_allowed mask won't get back that cpu
>>> when it becomes online again. A possible workaround for this type of
>>> cpu offline/online sequence is to leave the offline cpu in the task's
>>> cpumask and do the update only if new cpus are added. It also has the
>>> benefit of reducing the overhead of a cpu offline event.
>>>
>>> Note that the scheduler is able to ignore the offline cpus and so
>>> leaving offline cpus in the cpumask won't do any harm.
>>>
>>> Now with v2, only the cpu online events will cause a call to
>>> hotplug_update_tasks() to update the tasks' cpumasks. For tasks
>>> in a non-root v1 cpuset, the situation is a bit different. The cpu
>>> offline event will not cause change to a task's cpumask. Neither does a
>>> subsequent cpu online event because "cpuset.cpus" had that offline cpu
>>> removed and its subsequent onlining won't be registered as a change
>>> to the cpuset. An exception is when all the cpus in the original
>>> "cpuset.cpus" have gone offline once. In that case, "cpuset.cpus" will
>>> become empty which will force task migration to its parent. A task's
>>> cpumask will also be changed if set_cpus_allowed_ptr() is somehow 
>>> called
>>> for whatever reason.
>>>
>>> Of course, this patch can cause a discrepancy between v1's 
>>> "cpuset.cpus"
>>> and and its tasks' cpumasks. Howver, it can also largely work around
>>> the offline cpu losing problem with v1 cpuset.
>> I don't thikn you can simply not update on offline, even if
>> effective_cpus doesn't go empty, because the intersection between
>> task_cpu_possible_mask() and effective_cpus might have gone empty.
>>
>> Very fundamentally, the introduction of task_cpu_possible_mask() means
>> that you now *HAVE* to always consider affinity settings per-task, you
>> cannot group them anymore.
>
> Right, it makes sense to me. That is why I am thinking that we should 
> have an API like may_have_task_cpu_possible_mask() that returns true 
> for heterogeneous systems. That will allow us to apply some 
> optimizations in systems with homogeneous cpus. So far, this is an 
> arm64 only feature. We shouldn't penalize other arches because arm64 
> needs that. In the future, maybe more arches will have that.

It turns out there still gaps in the handling of 
task_cpu_possible_mask() in existing cpuset code. We currently do not 
check for the returned value of set_cpus_allowed_ptr() which may fails 
in case task_cpu_possible_mask() returns a different mask. I think it 
may be too late for the upcoming merge window. I am planning to have 
that addressed in the next one.

In the case of cpu offline, one possible solution may be to move the 
task to its parent like what is done for v1 when effective_cpus becomes 
empty. In the case of cpuset.cpus update, perhaps just ignore the 
failure and print an info message about that.

Cheers,
Longman