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
