| Message ID | 20241217-isolcpus-io-queues-v4-8-5d355fbb1e14@kernel.org |
|---|---|
| State | New |
| Headers | show |
| Series | blk: honor isolcpus configuration | expand |
On Tue, Dec 17, 2024 at 07:29:42PM +0100, Daniel Wagner wrote: > When isolcpus=managed_irq is enabled all hardware queues should run on > the housekeeping CPUs only. Thus ignore the affinity mask provided by > the driver. Also we can't use blk_mq_map_queues because it will map all > CPUs to first hctx unless, the CPU is the same as the hctx has the > affinity set to, e.g. 8 CPUs with isolcpus=managed_irq,2-3,6-7 config > > queue mapping for /dev/nvme0n1 > hctx0: default 2 3 4 6 7 > hctx1: default 5 > hctx2: default 0 > hctx3: default 1 > > PCI name is 00:05.0: nvme0n1 > irq 57 affinity 0-1 effective 1 is_managed:0 nvme0q0 > irq 58 affinity 4 effective 4 is_managed:1 nvme0q1 > irq 59 affinity 5 effective 5 is_managed:1 nvme0q2 > irq 60 affinity 0 effective 0 is_managed:1 nvme0q3 > irq 61 affinity 1 effective 1 is_managed:1 nvme0q4 > > where as with blk_mq_hk_map_queues we get > > queue mapping for /dev/nvme0n1 > hctx0: default 2 4 > hctx1: default 3 5 > hctx2: default 0 6 > hctx3: default 1 7 > > PCI name is 00:05.0: nvme0n1 > irq 56 affinity 0-1 effective 1 is_managed:0 nvme0q0 > irq 61 affinity 4 effective 4 is_managed:1 nvme0q1 > irq 62 affinity 5 effective 5 is_managed:1 nvme0q2 > irq 63 affinity 0 effective 0 is_managed:1 nvme0q3 > irq 64 affinity 1 effective 1 is_managed:1 nvme0q4 > > Signed-off-by: Daniel Wagner <wagi@kernel.org> > --- > block/blk-mq-cpumap.c | 66 +++++++++++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 66 insertions(+) > > diff --git a/block/blk-mq-cpumap.c b/block/blk-mq-cpumap.c > index b3a863c2db3231624685ab54a1810b22af4111f4..38016bf1be8af14ef368e68d3fd12416858e3da6 100644 > --- a/block/blk-mq-cpumap.c > +++ b/block/blk-mq-cpumap.c > @@ -61,11 +61,74 @@ unsigned int blk_mq_num_online_queues(unsigned int max_queues) > } > EXPORT_SYMBOL_GPL(blk_mq_num_online_queues); > > +/* > + * blk_mq_map_hk_queues - Create housekeeping CPU to hardware queue mapping > + * @qmap: CPU to hardware queue map > + * > + * Create a housekeeping CPU to hardware queue mapping in @qmap. If the > + * isolcpus feature is enabled and blk_mq_map_hk_queues returns true, > + * @qmap contains a valid configuration honoring the managed_irq > + * configuration. If the isolcpus feature is disabled this function > + * returns false. > + */ > +static bool blk_mq_map_hk_queues(struct blk_mq_queue_map *qmap) > +{ > + struct cpumask *hk_masks; > + cpumask_var_t isol_mask; > + unsigned int queue, cpu, nr_masks; > + > + if (!housekeeping_enabled(HK_TYPE_MANAGED_IRQ)) > + return false; > + > + /* map housekeeping cpus to matching hardware context */ > + nr_masks = qmap->nr_queues; > + hk_masks = group_cpus_evenly(&nr_masks); > + if (!hk_masks) > + goto fallback; > + > + for (queue = 0; queue < qmap->nr_queues; queue++) { > + for_each_cpu(cpu, &hk_masks[queue % nr_masks]) > + qmap->mq_map[cpu] = qmap->queue_offset + queue; > + } > + > + kfree(hk_masks); > + > + /* map isolcpus to hardware context */ > + if (!alloc_cpumask_var(&isol_mask, GFP_KERNEL)) > + goto fallback; > + > + queue = 0; > + cpumask_andnot(isol_mask, > + cpu_possible_mask, > + housekeeping_cpumask(HK_TYPE_MANAGED_IRQ)); > + > + for_each_cpu(cpu, isol_mask) { > + qmap->mq_map[cpu] = qmap->queue_offset + queue; > + queue = (queue + 1) % qmap->nr_queues; > + } Looks the IO hang issue in V3 isn't addressed yet, is it? https://lore.kernel.org/linux-block/ZrtX4pzqwVUEgIPS@fedora/ Thanks, Ming
On Thu, Dec 19, 2024 at 04:38:43PM +0100, Daniel Wagner wrote: > When isolcpus=managed_irq is enabled all hardware queues should run on > the housekeeping CPUs only. Thus ignore the affinity mask provided by > the driver. Compared with in-tree code, the above words are misleading. - irq core code respects isolated CPUs by trying to exclude isolated CPUs from effective masks - blk-mq won't schedule blockd on isolated CPUs If application aren't run on isolated CPUs, IO interrupt usually won't be triggered on isolated CPUs, so isolated CPUs are _not_ ignored. > On Thu, Dec 19, 2024 at 05:20:44PM +0800, Ming Lei wrote: > > > + cpumask_andnot(isol_mask, > > > + cpu_possible_mask, > > > + housekeeping_cpumask(HK_TYPE_MANAGED_IRQ)); > > > + > > > + for_each_cpu(cpu, isol_mask) { > > > + qmap->mq_map[cpu] = qmap->queue_offset + queue; > > > + queue = (queue + 1) % qmap->nr_queues; > > > + } > > > > Looks the IO hang issue in V3 isn't addressed yet, is it? > > > > https://lore.kernel.org/linux-block/ZrtX4pzqwVUEgIPS@fedora/ > > I've added an explanation in the cover letter why this is not > addressed. From the cover letter: > > I've experimented for a while and all solutions I came up were horrible > hacks (the hotpath needs to be touched) and I don't want to slow down all > other users (which are almost everyone). IMO, it's just not worth trying IMO, this patchset is one improvement on existed best-effort approach, which works fine most of times, so why you do think it slows down everyone? > to fix this corner case. If the user is using isolcpus and does CPU > hotplug, we can expect that the user can also first offline the isolated > CPUs. I've discussed this topic during ALPSS and the room came to the > same conclusion. Thus I just added a patch which issues a warning that > IOs are likely to hang. If the change need userspace cooperation for using 'managed_irq', the exact behavior need to be documented in both this commit and Documentation/admin-guide/kernel-parameters.txt, instead of cover-letter only. But this patch does cause regression for old applications which can't follow the new introduced rule: ``` If the user is using isolcpus and does CPU hotplug, we can expect that the user can also first offline the isolated CPUs. ``` Thanks, Ming
diff --git a/block/blk-mq-cpumap.c b/block/blk-mq-cpumap.c index b3a863c2db3231624685ab54a1810b22af4111f4..38016bf1be8af14ef368e68d3fd12416858e3da6 100644 --- a/block/blk-mq-cpumap.c +++ b/block/blk-mq-cpumap.c @@ -61,11 +61,74 @@ unsigned int blk_mq_num_online_queues(unsigned int max_queues) } EXPORT_SYMBOL_GPL(blk_mq_num_online_queues); +/* + * blk_mq_map_hk_queues - Create housekeeping CPU to hardware queue mapping + * @qmap: CPU to hardware queue map + * + * Create a housekeeping CPU to hardware queue mapping in @qmap. If the + * isolcpus feature is enabled and blk_mq_map_hk_queues returns true, + * @qmap contains a valid configuration honoring the managed_irq + * configuration. If the isolcpus feature is disabled this function + * returns false. + */ +static bool blk_mq_map_hk_queues(struct blk_mq_queue_map *qmap) +{ + struct cpumask *hk_masks; + cpumask_var_t isol_mask; + unsigned int queue, cpu, nr_masks; + + if (!housekeeping_enabled(HK_TYPE_MANAGED_IRQ)) + return false; + + /* map housekeeping cpus to matching hardware context */ + nr_masks = qmap->nr_queues; + hk_masks = group_cpus_evenly(&nr_masks); + if (!hk_masks) + goto fallback; + + for (queue = 0; queue < qmap->nr_queues; queue++) { + for_each_cpu(cpu, &hk_masks[queue % nr_masks]) + qmap->mq_map[cpu] = qmap->queue_offset + queue; + } + + kfree(hk_masks); + + /* map isolcpus to hardware context */ + if (!alloc_cpumask_var(&isol_mask, GFP_KERNEL)) + goto fallback; + + queue = 0; + cpumask_andnot(isol_mask, + cpu_possible_mask, + housekeeping_cpumask(HK_TYPE_MANAGED_IRQ)); + + for_each_cpu(cpu, isol_mask) { + qmap->mq_map[cpu] = qmap->queue_offset + queue; + queue = (queue + 1) % qmap->nr_queues; + } + + free_cpumask_var(isol_mask); + + return true; + +fallback: + /* map all cpus to hardware context ignoring any affinity */ + queue = 0; + for_each_possible_cpu(cpu) { + qmap->mq_map[cpu] = qmap->queue_offset + queue; + queue = (queue + 1) % qmap->nr_queues; + } + return true; +} + void blk_mq_map_queues(struct blk_mq_queue_map *qmap) { const struct cpumask *masks; unsigned int queue, cpu, nr_masks; + if (blk_mq_map_hk_queues(qmap)) + return; + nr_masks = qmap->nr_queues; masks = group_cpus_evenly(&nr_masks); if (!masks) { @@ -121,6 +184,9 @@ void blk_mq_map_hw_queues(struct blk_mq_queue_map *qmap, if (!dev->bus->irq_get_affinity) goto fallback; + if (blk_mq_map_hk_queues(qmap)) + return; + for (queue = 0; queue < qmap->nr_queues; queue++) { mask = dev->bus->irq_get_affinity(dev, queue + offset); if (!mask)
When isolcpus=managed_irq is enabled all hardware queues should run on the housekeeping CPUs only. Thus ignore the affinity mask provided by the driver. Also we can't use blk_mq_map_queues because it will map all CPUs to first hctx unless, the CPU is the same as the hctx has the affinity set to, e.g. 8 CPUs with isolcpus=managed_irq,2-3,6-7 config queue mapping for /dev/nvme0n1 hctx0: default 2 3 4 6 7 hctx1: default 5 hctx2: default 0 hctx3: default 1 PCI name is 00:05.0: nvme0n1 irq 57 affinity 0-1 effective 1 is_managed:0 nvme0q0 irq 58 affinity 4 effective 4 is_managed:1 nvme0q1 irq 59 affinity 5 effective 5 is_managed:1 nvme0q2 irq 60 affinity 0 effective 0 is_managed:1 nvme0q3 irq 61 affinity 1 effective 1 is_managed:1 nvme0q4 where as with blk_mq_hk_map_queues we get queue mapping for /dev/nvme0n1 hctx0: default 2 4 hctx1: default 3 5 hctx2: default 0 6 hctx3: default 1 7 PCI name is 00:05.0: nvme0n1 irq 56 affinity 0-1 effective 1 is_managed:0 nvme0q0 irq 61 affinity 4 effective 4 is_managed:1 nvme0q1 irq 62 affinity 5 effective 5 is_managed:1 nvme0q2 irq 63 affinity 0 effective 0 is_managed:1 nvme0q3 irq 64 affinity 1 effective 1 is_managed:1 nvme0q4 Signed-off-by: Daniel Wagner <wagi@kernel.org> --- block/blk-mq-cpumap.c | 66 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 66 insertions(+)