On Fri, Jul 04, 2025 at 12:28:49PM +0200, Hannes Reinecke wrote: > It really shouldn't be an issue when the cpus are distributed 'correctly' > :-)
If I get the drift, we start to discuss how the mapping could be normally, so not for isolcpus. The isolcpus case is just how many hwq are available (and affinity): num queues to map = min(num housekeeping CPUs, #hwq) and then it's common code, no special housekeeping mapping code. > We have several possibilities: > -> #hwq > num_possible_cpus: easy, 1:1 mapping, no problem I agree, no problem here. > -> num_online_cpu < #hwq < num_possible_cpus: Not as easy, but if we > ensure that each online cpu is mapped to a different hwq we don't > have a performance impact. This should also be fairly straightforward too. First assign each online CPU a hwq and distribute the rest of the hwq amount the rest of the possible offline CPUs. > -> #hwq < num_online_cpu: If we ensure that a) the number of online cpus > per hwq is (roughly) identical we won't have a performance impact. > As a bonus we should strive to have the number of offline cpus > distributed equally on each hwq. __group_cpus_evenly is handling this pretty well. > Of course, that doesn't take into accound NUMA locality; with NUMA locality > you would need to ensure to have at least one CPU per NUMA node > mapped to each hwq. Which actually would impose a lower limit on the > number (and granularity!) of hwqs (namely the number of NUMA nodes), but > that's fair, I guess. Again __group_cpus_evenly is taking NUMA into account as I understand it. > But this really can be delegated to later patches; initially we really > should identify which drivers might have issues with CPU hotplug, > and at the very least issue a warning for these drivers. There are different ways I suppose. My approach is not to change the drivers too much because I don't have access to all the hardware for testing. Instead extend the core code so that the different cases are covered.
