Re: [PATCH v2 2/2] cgroup/cpuset: Don't update tasks' cpumasks for cpu offline events

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]     [Monitors]

  Powered by Linux