Linus,
please pull the latest irq-core-for-linus git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git irq-core-for-linus
The irq department delivers:
- Expand the generic infrastructure handling the irq migration on CPU
hotplug and convert X86 over to it. (Thomas Gleixner)
Aside of consolidating code this is a preparatory change for:
- Finalizing the affinity management for multi-queue devices. The main
change here is to shut down interrupts which are affine to a outgoing
CPU and reenabling them when the CPU comes online again. That avoids
moving interrupts pointlessly around and breaking and reestablishing
affinities for no value. (Christoph Hellwig)
Note: This contains also the BLOCK-MQ and NVME changes which depend
on the rework of the irq core infrastructure. Jens acked them and
agreed that they should go with the irq changes.
- Consolidation of irq domain code (Marc Zyngier)
- State tracking consolidation in the core code (Jeffy Chen)
- Add debug infrastructure for hierarchical irq domains (Thomas Gleixner)
- Infrastructure enhancement for managing generic interrupt chips via
devmem (Bartosz Golaszewski)
- Constification work all over the place (Tobias Klauser)
- Two new interrupt controller drivers for MVEBU (Thomas Petazzoni)
- The usual set of fixes, updates and enhancements all over the place.
Thanks,
tglx
------------------>
Andrew Jeffery (1):
irqchip/aspeed-vic: Add AST2500 compatible string
Arvind Yadav (2):
irqchip/gic-v3-its: Make of_device_ids const
irqchip/gic-v3-its-platform-msi: Make of_device_ids const
Bartosz Golaszewski (5):
irq/generic-chip: Provide irq_free_generic_chip()
irq/generic-chip: Provide irq_destroy_generic_chip()
irq/generic-chip: Export irq_init_generic_chip() locally
irq/generic-chip: Provide devm_irq_alloc_generic_chip()
irq/generic-chip: Provide devm_irq_setup_generic_chip()
Brendan Higgins (2):
irqchip/aspeed-i2c-ic: Add binding docs for Aspeed I2C Interrupt Controller
irqchip/aspeed-i2c-ic: Add I2C IRQ controller for Aspeed
Chen-Yu Tsai (6):
irqchip/sunxi-nmi: Convert magic numbers to defines
irqchip/sunxi-nmi: Document interrupt disabling and clearing at probe time
irqchip/sunxi-nmi: Reorder sunxi_sc_nmi_reg_offs' in ascending order
irqchip/sunxi-nmi: Const-ify sunxi_sc_nmi_reg_offs structures
dt-bindings/interrupt-controller: sunxi-nmi: Add compatible for A31 R_INTC
irqchip/sunxi-nmi: Support sun6i-a31-r-intc compatible
Christoph Hellwig (5):
genirq: Move pending helpers to internal.h
genirq/affinity: Assign vectors to all present CPUs
blk-mq: Include all present CPUs in the default queue mapping
blk-mq: Create hctx for each present CPU
nvme: Allocate queues for all possible CPUs
Dan Carpenter (1):
irqchip/irq-mvebu-gicp: Allocate enough memory for spi_bitmap
Daniel Lezcano (2):
genirq/timings: Add infrastructure to track the interrupt timings
genirq/timings: Add infrastructure for estimating the next interrupt arrival time
Ganapatrao Kulkarni (1):
irqchip/gic-v3-its: Add ACPI NUMA node mapping
Jeffy Chen (2):
genirq: Set irq masked state when initializing irq_desc
genirq: Avoid unnecessary low level irq function calls
MaJun (1):
irqchip/gicv3-its: Skip irq affinity setting when target cpu is the same as current setting
Marc Zyngier (7):
irqdomain: Let irq_domain_mapping display hierarchical domains
irqdomain: Let irq_domain_mapping display ACPI fwnode attributes
genirq/msi: Populate the domain name if provided by the irqchip
Documentation: Update IRQ-domain.txt to document irq_domain_mapping
genirq/irqdomain: Add irq_domain_update_bus_token helper
irqchip/MSI: Use irq_domain_update_bus_token instead of an open coded access
genirq/irqdomain: Remove auto-recursive hierarchy support
Pedro H. Penna (1):
irqchip/or1k-pic: Fix interrupt acknowledgement
Robin Murphy (1):
irqchip/gic-v3-its: Fix MSI alias accounting
Shanker Donthineni (1):
irqchip/gic-v3-its: Don't assume GICv3 hardware supports 16bit INTID
Suzuki K Poulose (1):
irqchip/gic-v3: Fix out-of-bound access in gic_set_affinity
Thomas Gleixner (56):
genirq: Handle NOAUTOEN interrupt setup proper
genirq: Warn when IRQ_NOAUTOEN is used with shared interrupts
x86/apic: Add name to irq chip
iommu/amd: Add name to irq chip
iommu/vt-d: Add name to irq chip
genirq/msi: Prevent overwriting domain name
genirq: Allow fwnode to carry name information only
x86/vector: Create named irq domain
x86/ioapic: Create named irq domain
x86/htirq: Create named domain
x86/uv: Create named irq domain
x86/msi: Provide new iommu irqdomain interface
iommu/vt-d: Use named irq domain interface
iommu/amd: Use named irq domain interface
x86/msi: Remove unused remap irq domain interface
x86/msi: Create named irq domains
PCI/vmd: Create named irq domain
genirq/irqdomain: Add map counter
genirq/debugfs: Add proper debugfs interface
genirq: Add missing comment for IRQD_STARTED
genirq: Provide irq_fixup_move_pending()
x86/irq: Cleanup pending irq move in fixup_irqs()
genirq: Remove mask argument from setup_affinity()
genirq: Rename setup_affinity() to irq_setup_affinity()
genirq: Move initial affinity setup to irq_startup()
genirq/cpuhotplug: Remove irq disabling logic
genirq/cpuhotplug: Dont claim success on error
genirq/cpuhotplug: Reorder check logic
genirq/cpuhotplug: Do not migrated shutdown irqs
genirq/cpuhotplug: Add support for cleaning up move in progress
genirq/cpuhotplug: Add support for conditional masking
genirq/cpuhotplug: Set force affinity flag on hotplug migration
x86/irq: Restructure fixup_irqs()
x86/irq: Use irq_migrate_all_off_this_cpu()
genirq: Move irq_fixup_move_pending() to core
genirq: Remove pointless arg from show_irq_affinity
genirq: Remove pointless gfp argument
genirq/proc: Replace ever repeating type cast
genirq: Introduce effective affinity mask
genirq/cpuhotplug: Use effective affinity mask
x86/apic: Move flat_cpu_mask_to_apicid_and() into C source
x86/uv: Use default_cpu_mask_to_apicid_and()
x86/apic: Move online masking to core code
x86/apic: Move cpumask and to core code
x86/apic: Add irq_data argument to apic->cpu_mask_to_apicid()
xen/events: Add support for effective affinity mask
x86/apic: Implement effective irq mask update
genirq: Introduce IRQD_MANAGED_SHUTDOWN
genirq: Split out irq_startup() code
genirq: Add force argument to irq_startup()
genirq: Handle managed irqs gracefully in irq_startup()
genirq/cpuhotplug: Handle managed IRQs on CPU hotplug
genirq: Introduce IRQD_SINGLE_TARGET flag
genirq/cpuhotplug: Avoid irq affinity setting for single targets
x86/apic: Mark single target interrupts
genirq/debugfs: Remove pointless NULL pointer check
Thomas Petazzoni (8):
irqchip/armada-370-xp: Re-order register definitions
irqchip/armada-370-xp: Document the overall driver logic
irqchip/armada-370-xp: Re-enable per-CPU interrupts at resume time
Revert "irqchip/armada-370-xp: Fix regression by clearing IRQ_NOAUTOEN"
dt-bindings/interrupt-controller: Add DT binding for the Marvell GICP
dt-bindings/interrupt-controller: Add DT binding for the Marvell ICU
irqchip/irq-mvebu-gicp: Add new driver for Marvell GICP
irqchip/irq-mvebu-icu: Add new driver for Marvell ICU
Tobias Klauser (7):
irqchip/i8259: Constify irq_domain_ops
irqchip/irq-imx-gpcv2: Constify irq_domain_ops
irqchip/irq-mbigen: Constify irq_domain_ops
irqchip/irq-mips-gic: Constify irq_domain_ops
irqchip/irq-renesas-h8300h: Constify irq_domain_ops
irqchip/irq-renesas-h8s: Constify irq_domain_ops
irqchip/aspeed-vic: Constify irq_domain_ops
Vincent Legoll (1):
genirq: Make early_irq_init() print out more informative
Wei Yongjun (1):
irqchip/qcom: Use builtin_platform_driver to simplify the code
Patch omitted for size reasons
Documentation/IRQ-domain.txt | 41 ++-
.../interrupt-controller/allwinner,sunxi-nmi.txt | 7 +-
.../interrupt-controller/aspeed,ast2400-i2c-ic.txt | 25 ++
.../interrupt-controller/aspeed,ast2400-vic.txt | 9 +-
.../bindings/interrupt-controller/marvell,gicp.txt | 27 ++
.../bindings/interrupt-controller/marvell,icu.txt | 51 +++
Documentation/driver-model/devres.txt | 2 +
arch/x86/Kconfig | 2 +
arch/x86/include/asm/apic.h | 36 +-
arch/x86/include/asm/irq.h | 1 -
arch/x86/include/asm/irq_remapping.h | 3 +-
arch/x86/kernel/apic/apic.c | 35 +-
arch/x86/kernel/apic/apic_flat_64.c | 4 +-
arch/x86/kernel/apic/apic_noop.c | 2 +-
arch/x86/kernel/apic/apic_numachip.c | 4 +-
arch/x86/kernel/apic/bigsmp_32.c | 2 +-
arch/x86/kernel/apic/htirq.c | 21 +-
arch/x86/kernel/apic/io_apic.c | 22 +-
arch/x86/kernel/apic/msi.c | 55 ++-
arch/x86/kernel/apic/probe_32.c | 2 +-
arch/x86/kernel/apic/vector.c | 49 ++-
arch/x86/kernel/apic/x2apic_cluster.c | 36 +-
arch/x86/kernel/apic/x2apic_phys.c | 2 +-
arch/x86/kernel/apic/x2apic_uv_x.c | 26 +-
arch/x86/kernel/irq.c | 78 +----
arch/x86/platform/uv/uv_irq.c | 18 +-
arch/x86/xen/apic.c | 2 +-
block/blk-mq-cpumap.c | 5 +-
block/blk-mq.c | 120 +------
block/blk-mq.h | 5 -
drivers/base/platform-msi.c | 2 +-
drivers/iommu/amd_iommu.c | 22 +-
drivers/iommu/intel_irq_remapping.c | 31 +-
drivers/irqchip/Kconfig | 6 +
drivers/irqchip/Makefile | 4 +-
drivers/irqchip/irq-armada-370-xp.c | 148 ++++++++-
drivers/irqchip/irq-aspeed-i2c-ic.c | 115 +++++++
drivers/irqchip/irq-aspeed-vic.c | 5 +-
drivers/irqchip/irq-gic-v2m.c | 2 +-
drivers/irqchip/irq-gic-v3-its-pci-msi.c | 35 +-
drivers/irqchip/irq-gic-v3-its-platform-msi.c | 2 +-
drivers/irqchip/irq-gic-v3-its.c | 113 +++++--
drivers/irqchip/irq-gic-v3.c | 3 +
drivers/irqchip/irq-i8259.c | 2 +-
drivers/irqchip/irq-imx-gpcv2.c | 2 +-
drivers/irqchip/irq-mbigen.c | 2 +-
drivers/irqchip/irq-mips-cpu.c | 2 +-
drivers/irqchip/irq-mips-gic.c | 4 +-
drivers/irqchip/irq-mvebu-gicp.c | 279 ++++++++++++++++
drivers/irqchip/irq-mvebu-gicp.h | 11 +
drivers/irqchip/irq-mvebu-icu.c | 289 ++++++++++++++++
drivers/irqchip/irq-or1k-pic.c | 2 +-
drivers/irqchip/irq-renesas-h8300h.c | 2 +-
drivers/irqchip/irq-renesas-h8s.c | 2 +-
drivers/irqchip/irq-sunxi-nmi.c | 68 +++-
drivers/irqchip/qcom-irq-combiner.c | 7 +-
drivers/nvme/host/pci.c | 2 +-
drivers/pci/host/vmd.c | 8 +-
drivers/pci/msi.c | 2 +-
drivers/staging/fsl-mc/bus/fsl-mc-msi.c | 2 +-
drivers/xen/events/events_base.c | 6 +-
.../dt-bindings/interrupt-controller/mvebu-icu.h | 15 +
include/linux/cpuhotplug.h | 2 +-
include/linux/interrupt.h | 6 +
include/linux/irq.h | 89 +++++
include/linux/irqdesc.h | 4 +
include/linux/irqdomain.h | 43 ++-
kernel/cpu.c | 5 +
kernel/irq/Kconfig | 18 +
kernel/irq/Makefile | 2 +
kernel/irq/affinity.c | 76 ++++-
kernel/irq/autoprobe.c | 4 +-
kernel/irq/chip.c | 195 ++++++++---
kernel/irq/cpuhotplug.c | 150 +++++++--
kernel/irq/debugfs.c | 213 ++++++++++++
kernel/irq/devres.c | 86 +++++
kernel/irq/generic-chip.c | 7 +-
kernel/irq/handle.c | 2 +
kernel/irq/internals.h | 225 ++++++++++++-
kernel/irq/irqdesc.c | 36 +-
kernel/irq/irqdomain.c | 359 +++++++++++++++-----
kernel/irq/manage.c | 119 +++----
kernel/irq/migration.c | 30 ++
kernel/irq/msi.c | 13 +-
kernel/irq/proc.c | 110 +++++-
kernel/irq/timings.c | 369 +++++++++++++++++++++
86 files changed, 3342 insertions(+), 708 deletions(-)
create mode 100644 Documentation/devicetree/bindings/interrupt-controller/aspeed,ast2400-i2c-ic.txt
create mode 100644 Documentation/devicetree/bindings/interrupt-controller/marvell,gicp.txt
create mode 100644 Documentation/devicetree/bindings/interrupt-controller/marvell,icu.txt
create mode 100644 drivers/irqchip/irq-aspeed-i2c-ic.c
create mode 100644 drivers/irqchip/irq-mvebu-gicp.c
create mode 100644 drivers/irqchip/irq-mvebu-gicp.h
create mode 100644 drivers/irqchip/irq-mvebu-icu.c
create mode 100644 include/dt-bindings/interrupt-controller/mvebu-icu.h
create mode 100644 kernel/irq/debugfs.c
create mode 100644 kernel/irq/timings.c
On Mon, Jul 3, 2017 at 12:42 AM, Thomas Gleixner <[email protected]> wrote:
>
> please pull the latest irq-core-for-linus git tree from:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git irq-core-for-linus
Ugh, this caused conflicts with the block tree, with commits
- fe631457ff3e: "blk-mq: map all HWQ also in hyperthreaded system"
- 5f042e7cbd9e "blk-mq: Include all present CPUs in the default queue mapping"
clashing.
I'm not at all understanding why that second commit came in through
the irq tree at all, in fact. Very annoying. Why was that not sent
through the block tree? It doesn't seem to have anything fundamentally
to do with irqs, really: it's a driver CPU choice for irq chocie.
Anyway, I absolutely detested that code, and the obvious resolution
was too disgusting to live. So I did an evil merge and moved some
things around in the merge to make it at least not cause me to dig my
eyes out.
But I'd like people to look at that - not so much due to the evil
merge itself (but check that too, by any means), but just because the
code seems fundamentally broken for the hotplug case. We end up
picking a possible metric shit-ton of CPU's for queue 0, if they were
"possible but not online".
If they ever do come online, does that get fixed? I don't know.
Somebody should check.
Linus
On Mon, 3 Jul 2017, Linus Torvalds wrote:
> On Mon, Jul 3, 2017 at 12:42 AM, Thomas Gleixner <[email protected]> wrote:
> >
> > please pull the latest irq-core-for-linus git tree from:
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git irq-core-for-linus
>
> Ugh, this caused conflicts with the block tree, with commits
>
> - fe631457ff3e: "blk-mq: map all HWQ also in hyperthreaded system"
>
> - 5f042e7cbd9e "blk-mq: Include all present CPUs in the default queue mapping"
>
> clashing.
>
> I'm not at all understanding why that second commit came in through
> the irq tree at all, in fact. Very annoying. Why was that not sent
> through the block tree? It doesn't seem to have anything fundamentally
> to do with irqs, really: it's a driver CPU choice for irq chocie.
There is a dependency. The changes in the block code rely on the new
features of the generic interrupt affinity management. See below.
> Anyway, I absolutely detested that code, and the obvious resolution
> was too disgusting to live. So I did an evil merge and moved some
> things around in the merge to make it at least not cause me to dig my
> eyes out.
>
> But I'd like people to look at that - not so much due to the evil
> merge itself (but check that too, by any means), but just because the
> code seems fundamentally broken for the hotplug case. We end up
> picking a possible metric shit-ton of CPU's for queue 0, if they were
> "possible but not online".
The mechanism is:
Spread out the queues and the associated interrupts accross the possible
CPUs. This results in a queue/interrupt per group of CPUs (group can be a
single CPU)
If a group is offline, then the interrupt is kept in managed shutdown
mode. If a CPU of the group comes online then the core management starts up
the interrupt and makes it affine to that CPU.
If the last CPU of a group goes offline, the interrupt is not moved to some
random other CPU. It's put in managed shutdown mode and then restarted when
the a CPU of the group comes online again.
That exercise avoids exactly the 'metric tons of irqs' moved to random CPUs
and then brought back to the target CPUs when they come online
again. On/offline seems to be (ab)used frequently for power management
purposes nowadays.
Sorry, if I did not make that clear enough in the pull request message.
Thanks,
tglx
On Tue, 4 Jul 2017, Thomas Gleixner wrote:
> On Mon, 3 Jul 2017, Linus Torvalds wrote:
>
> > On Mon, Jul 3, 2017 at 12:42 AM, Thomas Gleixner <[email protected]> wrote:
> > >
> > > please pull the latest irq-core-for-linus git tree from:
> > >
> > > git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git irq-core-for-linus
> >
> > Ugh, this caused conflicts with the block tree, with commits
> >
> > - fe631457ff3e: "blk-mq: map all HWQ also in hyperthreaded system"
> >
> > - 5f042e7cbd9e "blk-mq: Include all present CPUs in the default queue mapping"
> >
> > clashing.
> >
> > I'm not at all understanding why that second commit came in through
> > the irq tree at all, in fact. Very annoying. Why was that not sent
> > through the block tree? It doesn't seem to have anything fundamentally
> > to do with irqs, really: it's a driver CPU choice for irq chocie.
>
> There is a dependency. The changes in the block code rely on the new
> features of the generic interrupt affinity management. See below.
That said, we should have kept the colliding changes back, wait until
block and irq got merged and then apply them again properly.
Sorry for the inconveniance.
Thanks,
tglx
On 07/03/2017 06:00 PM, Linus Torvalds wrote:
> But I'd like people to look at that - not so much due to the evil
> merge itself (but check that too, by any means), but just because the
> code seems fundamentally broken for the hotplug case. We end up
> picking a possible metric shit-ton of CPU's for queue 0, if they were
> "possible but not online".
>
> If they ever do come online, does that get fixed? I don't know.
> Somebody should check.
Yes, the blk-mq cpu hotplug code updates mappings when CPUs come and
go, so that part is fine. That's exercised everytime the laptop is
suspended and resumed.
--
Jens Axboe
On Tue, Jul 4, 2017 at 8:17 AM, Jens Axboe <[email protected]> wrote:
> On 07/03/2017 06:00 PM, Linus Torvalds wrote:
>>
>> If they ever do come online, does that get fixed? I don't know.
>> Somebody should check.
>
> Yes, the blk-mq cpu hotplug code updates mappings when CPUs come and
> go, so that part is fine. That's exercised everytime the laptop is
> suspended and resumed.
I don't think that's true any more. Commit fe631457ff3e changed it to
map the initial CPU's sequentially whether they are online or not.
Only after you run out of hardware queues will we start playing games.
That's what worries me about the conflict - the two changes did very
different things to the same code. I'd really like somebody to take a
look at my resolution, and just in general how those two different
changes work together.
Linus
On Tue, 4 Jul 2017, Linus Torvalds wrote:
> On Tue, Jul 4, 2017 at 8:17 AM, Jens Axboe <[email protected]> wrote:
> > On 07/03/2017 06:00 PM, Linus Torvalds wrote:
> >>
> >> If they ever do come online, does that get fixed? I don't know.
> >> Somebody should check.
> >
> > Yes, the blk-mq cpu hotplug code updates mappings when CPUs come and
> > go, so that part is fine. That's exercised everytime the laptop is
> > suspended and resumed.
>
> I don't think that's true any more. Commit fe631457ff3e changed it to
> map the initial CPU's sequentially whether they are online or not.
> Only after you run out of hardware queues will we start playing games.
>
> That's what worries me about the conflict - the two changes did very
> different things to the same code. I'd really like somebody to take a
> look at my resolution, and just in general how those two different
> changes work together.
Hmm, I leave that to Christoph. He wrote the irq stuff and reviewed
fe631457ff3e.
Thanks,
tglx
On 7/4/2017 10:10 PM, Thomas Gleixner wrote:
> On Tue, 4 Jul 2017, Linus Torvalds wrote:
>> On Tue, Jul 4, 2017 at 8:17 AM, Jens Axboe <[email protected]> wrote:
>>> On 07/03/2017 06:00 PM, Linus Torvalds wrote:
>>>>
>>>> If they ever do come online, does that get fixed? I don't know.
>>>> Somebody should check.
>>>
>>> Yes, the blk-mq cpu hotplug code updates mappings when CPUs come and
>>> go, so that part is fine. That's exercised everytime the laptop is
>>> suspended and resumed.
>>
>> I don't think that's true any more. Commit fe631457ff3e changed it to
>> map the initial CPU's sequentially whether they are online or not.
>> Only after you run out of hardware queues will we start playing games.
>>
>> That's what worries me about the conflict - the two changes did very
>> different things to the same code. I'd really like somebody to take a
>> look at my resolution, and just in general how those two different
>> changes work together.
>
> Hmm, I leave that to Christoph. He wrote the irq stuff and reviewed
> fe631457ff3e.
>
> Thanks,
>
> tglx
>
Hi Linus,
From code reviewing the changes you made during the merge, I'm good
with my commit purpose (fix the mapping between CPUs and HWQs). You
actually replaced the "struct cpumask *online_mask" with cpu_online(cpu)
function and it's fine. I'll run some tests to see that I'm not missing
something.
Regarding the second patch from Christoph, let's wait for his review (I
can also test other scenarios like offline/online CPU's after initial
mapping of CPUs to HWQs).
Cheers,
Max.
On 07/04/2017 12:34 PM, Linus Torvalds wrote:
> On Tue, Jul 4, 2017 at 8:17 AM, Jens Axboe <[email protected]> wrote:
>> On 07/03/2017 06:00 PM, Linus Torvalds wrote:
>>>
>>> If they ever do come online, does that get fixed? I don't know.
>>> Somebody should check.
>>
>> Yes, the blk-mq cpu hotplug code updates mappings when CPUs come and
>> go, so that part is fine. That's exercised everytime the laptop is
>> suspended and resumed.
>
> I don't think that's true any more. Commit fe631457ff3e changed it to
> map the initial CPU's sequentially whether they are online or not.
> Only after you run out of hardware queues will we start playing games.
>
> That's what worries me about the conflict - the two changes did very
> different things to the same code. I'd really like somebody to take a
> look at my resolution, and just in general how those two different
> changes work together.
OK, I'll take a look at it tomorrow.
--
Jens Axboe
On Mon, Jul 03, 2017 at 05:00:03PM -0700, Linus Torvalds wrote:
> I'm not at all understanding why that second commit came in through
> the irq tree at all, in fact. Very annoying. Why was that not sent
> through the block tree? It doesn't seem to have anything fundamentally
> to do with irqs, really: it's a driver CPU choice for irq chocie.
It depends on a major IRQ layer rework, and it had at that time no
clash with the block tree at all. That's why I suggested to Thomas
and Jens that we should take it through the irq code. Then Max'
code showed up last minute and wrecked that plan, and no one noticed
in time. Blame it on me for not noticing this in time.
> Anyway, I absolutely detested that code, and the obvious resolution
> was too disgusting to live. So I did an evil merge and moved some
> things around in the merge to make it at least not cause me to dig my
> eyes out.
>
> But I'd like people to look at that - not so much due to the evil
> merge itself (but check that too, by any means), but just because the
> code seems fundamentally broken for the hotplug case. We end up
> picking a possible metric shit-ton of CPU's for queue 0, if they were
> "possible but not online".
I think this code also needs to move over to cpu_possible instead
of cpu_online to match what we did for the MSI-X based mapping. But
I'll need a little more coffee and get back into it.
On 7/4/2017 11:48 PM, Max Gurtovoy wrote:
>
>
> On 7/4/2017 10:10 PM, Thomas Gleixner wrote:
>> On Tue, 4 Jul 2017, Linus Torvalds wrote:
>>> On Tue, Jul 4, 2017 at 8:17 AM, Jens Axboe <[email protected]> wrote:
>>>> On 07/03/2017 06:00 PM, Linus Torvalds wrote:
>>>>>
>>>>> If they ever do come online, does that get fixed? I don't know.
>>>>> Somebody should check.
>>>>
>>>> Yes, the blk-mq cpu hotplug code updates mappings when CPUs come and
>>>> go, so that part is fine. That's exercised everytime the laptop is
>>>> suspended and resumed.
>>>
>>> I don't think that's true any more. Commit fe631457ff3e changed it to
>>> map the initial CPU's sequentially whether they are online or not.
>>> Only after you run out of hardware queues will we start playing games.
>>>
>>> That's what worries me about the conflict - the two changes did very
>>> different things to the same code. I'd really like somebody to take a
>>> look at my resolution, and just in general how those two different
>>> changes work together.
>>
>> Hmm, I leave that to Christoph. He wrote the irq stuff and reviewed
>> fe631457ff3e.
>>
>> Thanks,
>>
>> tglx
>>
>
> Hi Linus,
> From code reviewing the changes you made during the merge, I'm good with
> my commit purpose (fix the mapping between CPUs and HWQs). You actually
> replaced the "struct cpumask *online_mask" with cpu_online(cpu) function
> and it's fine. I'll run some tests to see that I'm not missing something.
> Regarding the second patch from Christoph, let's wait for his review (I
> can also test other scenarios like offline/online CPU's after initial
> mapping of CPUs to HWQs).
>
> Cheers,
> Max.
FYI,
My tests for the mapping between (72) CPUs and (64) HWQs passed
successfully with 4.12.0+.