mbox series

[0/5] cgroup/cpuset: Miscellaneous updates

Message ID 20230306200849.376804-1-longman@redhat.com (mailing list archive)
Headers show
Series cgroup/cpuset: Miscellaneous updates | expand

Message

Waiman Long March 6, 2023, 8:08 p.m. UTC
This patch series includes miscellaneous update to the cpuset and its
testing code.

Patch 2 is actually a follow-up of commit 3fb906e7fabb ("cgroup/cpuset:
Don't filter offline CPUs in cpuset_cpus_allowed() for top cpuset tasks").

Patches 3-4 are for handling corner cases when dealing with
task_cpu_possible_mask().

Waiman Long (5):
  cgroup/cpuset: Skip task update if hotplug doesn't affect current
    cpuset
  cgroup/cpuset: Include offline CPUs when tasks' cpumasks in top_cpuset
    are updated
  cgroup/cpuset: Find another usable CPU if none found in current cpuset
  cgroup/cpuset: Add CONFIG_DEBUG_CPUSETS config for cpuset testing
  cgroup/cpuset: Minor updates to test_cpuset_prs.sh

 init/Kconfig                                  |   5 +
 kernel/cgroup/cpuset.c                        | 155 +++++++++++++++++-
 .../selftests/cgroup/test_cpuset_prs.sh       |  25 +--
 3 files changed, 165 insertions(+), 20 deletions(-)

Comments

Will Deacon March 15, 2023, 4:24 p.m. UTC | #1
Hi Waiman,

On Mon, Mar 06, 2023 at 03:08:44PM -0500, Waiman Long wrote:
> This patch series includes miscellaneous update to the cpuset and its
> testing code.
> 
> Patch 2 is actually a follow-up of commit 3fb906e7fabb ("cgroup/cpuset:
> Don't filter offline CPUs in cpuset_cpus_allowed() for top cpuset tasks").
> 
> Patches 3-4 are for handling corner cases when dealing with
> task_cpu_possible_mask().

Thanks for cc'ing me on these. I ran my arm64 asymmetric tests and, fwiw,
I get the same results as vanilla -rc2, so that's good.

One behaviour that persists (and which I thought might be addressed by this
series) is the following. Imagine a 4-CPU system with CPUs 0-1 being 64-bit
only. If I configure a parent cpuset with 'cpuset.cpus' of "0-2" and a
child cpuset with 'cpuset.cpus' of "0-1", then attaching a 32-bit task
to the child cpuset will result in an affinity mask of 4. If I then change
'cpuset.cpus' of the parent cpuset to "0-1,3", the affinity mask of the
task remains at '4' whereas it might be nice to update it to '8', in-line
with the new affinity mask of the parent cpuset.

Anyway, I'm not complaining (this is certainly _not_ a regression), but
I thought I'd highlight it in case you were aiming to address this with
your changes.

Cheers,

Will
Waiman Long March 15, 2023, 4:59 p.m. UTC | #2
On 3/15/23 12:24, Will Deacon wrote:
> Hi Waiman,
>
> On Mon, Mar 06, 2023 at 03:08:44PM -0500, Waiman Long wrote:
>> This patch series includes miscellaneous update to the cpuset and its
>> testing code.
>>
>> Patch 2 is actually a follow-up of commit 3fb906e7fabb ("cgroup/cpuset:
>> Don't filter offline CPUs in cpuset_cpus_allowed() for top cpuset tasks").
>>
>> Patches 3-4 are for handling corner cases when dealing with
>> task_cpu_possible_mask().
> Thanks for cc'ing me on these. I ran my arm64 asymmetric tests and, fwiw,
> I get the same results as vanilla -rc2, so that's good.
>
> One behaviour that persists (and which I thought might be addressed by this
> series) is the following. Imagine a 4-CPU system with CPUs 0-1 being 64-bit
> only. If I configure a parent cpuset with 'cpuset.cpus' of "0-2" and a
> child cpuset with 'cpuset.cpus' of "0-1", then attaching a 32-bit task
> to the child cpuset will result in an affinity mask of 4. If I then change
> 'cpuset.cpus' of the parent cpuset to "0-1,3", the affinity mask of the
> task remains at '4' whereas it might be nice to update it to '8', in-line
> with the new affinity mask of the parent cpuset.
>
> Anyway, I'm not complaining (this is certainly _not_ a regression), but
> I thought I'd highlight it in case you were aiming to address this with
> your changes.

I believe it is because changes in parent cpuset only won't cause the 
tasks in the child cpuset to be re-evaluated unless it causes a change 
in the effective_cpus of the child cpuset. This is the case here. We 
currently don't track how many tasks in the child cpusets are using 
parent's cpumask due to lacking runnable CPUs in the child cpuset. We 
can only fix this if we track those special tasks. It can be fixable, 
but I don't know if it is a problem that is worth fixing.

Cheers,
Longman