| Message ID | 20230306200849.376804-1-longman@redhat.com |
|---|---|
| Headers | show |
| Series | cgroup/cpuset: Miscellaneous updates | expand |
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
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
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(-)