| Message ID | 20210331144514.892250-9-clg@kaod.org (mailing list archive) |
|---|---|
| State | Accepted |
| Headers | show |
| Series | powerpc/xive: Map one IPI interrupt per node | expand |
| Context | Check | Description |
|---|---|---|
| snowpatch_ozlabs/apply_patch | success | Successfully applied on branch powerpc/merge (87d76f542a24ecfa797e9bd3bb56c0f19aabff57) |
| snowpatch_ozlabs/checkpatch | success | total: 0 errors, 0 warnings, 0 checks, 108 lines checked |
| snowpatch_ozlabs/needsstable | success | Patch has no Fixes tags |
Excerpts from Cédric Le Goater's message of April 1, 2021 12:45 am: > ipistorm [*] can be used to benchmark the raw interrupt rate of an > interrupt controller by measuring the number of IPIs a system can > sustain. When applied to the XIVE interrupt controller of POWER9 and > POWER10 systems, a significant drop of the interrupt rate can be > observed when crossing the second node boundary. > > This is due to the fact that a single IPI interrupt is used for all > CPUs of the system. The structure is shared and the cache line updates > impact greatly the traffic between nodes and the overall IPI > performance. > > As a workaround, the impact can be reduced by deactivating the IRQ > lockup detector ("noirqdebug") which does a lot of accounting in the > Linux IRQ descriptor structure and is responsible for most of the > performance penalty. > > As a fix, this proposal allocates an IPI interrupt per node, to be > shared by all CPUs of that node. It solves the scaling issue, the IRQ > lockup detector still has an impact but the XIVE interrupt rate scales > linearly. It also improves the "noirqdebug" case as showed in the > tables below. > > * P9 DD2.2 - 2s * 64 threads > > "noirqdebug" > Mint/s Mint/s > chips cpus IPI/sys IPI/chip IPI/chip IPI/sys > -------------------------------------------------------------- > 1 0-15 4.984023 4.875405 4.996536 5.048892 > 0-31 10.879164 10.544040 10.757632 11.037859 > 0-47 15.345301 14.688764 14.926520 15.310053 > 0-63 17.064907 17.066812 17.613416 17.874511 > 2 0-79 11.768764 21.650749 22.689120 22.566508 > 0-95 10.616812 26.878789 28.434703 28.320324 > 0-111 10.151693 31.397803 31.771773 32.388122 > 0-127 9.948502 33.139336 34.875716 35.224548 > > * P10 DD1 - 4s (not homogeneous) 352 threads > > "noirqdebug" > Mint/s Mint/s > chips cpus IPI/sys IPI/chip IPI/chip IPI/sys > -------------------------------------------------------------- > 1 0-15 2.409402 2.364108 2.383303 2.395091 > 0-31 6.028325 6.046075 6.089999 6.073750 > 0-47 8.655178 8.644531 8.712830 8.724702 > 0-63 11.629652 11.735953 12.088203 12.055979 > 0-79 14.392321 14.729959 14.986701 14.973073 > 0-95 12.604158 13.004034 17.528748 17.568095 > 2 0-111 9.767753 13.719831 19.968606 20.024218 > 0-127 6.744566 16.418854 22.898066 22.995110 > 0-143 6.005699 19.174421 25.425622 25.417541 > 0-159 5.649719 21.938836 27.952662 28.059603 > 0-175 5.441410 24.109484 31.133915 31.127996 > 3 0-191 5.318341 24.405322 33.999221 33.775354 > 0-207 5.191382 26.449769 36.050161 35.867307 > 0-223 5.102790 29.356943 39.544135 39.508169 > 0-239 5.035295 31.933051 42.135075 42.071975 > 0-255 4.969209 34.477367 44.655395 44.757074 > 4 0-271 4.907652 35.887016 47.080545 47.318537 > 0-287 4.839581 38.076137 50.464307 50.636219 > 0-303 4.786031 40.881319 53.478684 53.310759 > 0-319 4.743750 43.448424 56.388102 55.973969 > 0-335 4.709936 45.623532 59.400930 58.926857 > 0-351 4.681413 45.646151 62.035804 61.830057 > > [*] https://github.com/antonblanchard/ipistorm > > Cc: Thomas Gleixner <tglx@linutronix.de> > Signed-off-by: Cédric Le Goater <clg@kaod.org> Very nice result but the default-on irqdebug code is quite a slowdown even with your improvements. Is the main cacheline bouncing in the fast path coming from desc->irq_count++ of the percpu handler? Can we do something quick and dirty like the attached patch? All this stuff seems totally racy with percpu handler but maybe that doesn't matter too much (and anyway it would be a much bigger change) Thanks, Nick --- kernel/irq/spurious.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/kernel/irq/spurious.c b/kernel/irq/spurious.c index f865e5f4d382..6b17b737ee6c 100644 --- a/kernel/irq/spurious.c +++ b/kernel/irq/spurious.c @@ -378,7 +378,8 @@ void note_interrupt(struct irq_desc *desc, irqreturn_t action_ret) * then we merily delay the spurious detection * by one hard interrupt. Not a real problem. */ - desc->threads_handled_last &= ~SPURIOUS_DEFERRED; + if (desc->threads_handled_last & SPURIOUS_DEFERRED) + desc->threads_handled_last &= ~SPURIOUS_DEFERRED; } } @@ -403,6 +404,10 @@ void note_interrupt(struct irq_desc *desc, irqreturn_t action_ret) desc->irqs_unhandled -= ok; } + if (likely(!desc->irqs_unhandled)) + return; + + /* Now getting into unhandled irq detection */ desc->irq_count++; if (likely(desc->irq_count < 100000)) return;
On 4/1/21 2:50 PM, Nicholas Piggin wrote: > Excerpts from Cédric Le Goater's message of April 1, 2021 12:45 am: >> ipistorm [*] can be used to benchmark the raw interrupt rate of an >> interrupt controller by measuring the number of IPIs a system can >> sustain. When applied to the XIVE interrupt controller of POWER9 and >> POWER10 systems, a significant drop of the interrupt rate can be >> observed when crossing the second node boundary. >> >> This is due to the fact that a single IPI interrupt is used for all >> CPUs of the system. The structure is shared and the cache line updates >> impact greatly the traffic between nodes and the overall IPI >> performance. >> >> As a workaround, the impact can be reduced by deactivating the IRQ >> lockup detector ("noirqdebug") which does a lot of accounting in the >> Linux IRQ descriptor structure and is responsible for most of the >> performance penalty. >> >> As a fix, this proposal allocates an IPI interrupt per node, to be >> shared by all CPUs of that node. It solves the scaling issue, the IRQ >> lockup detector still has an impact but the XIVE interrupt rate scales >> linearly. It also improves the "noirqdebug" case as showed in the >> tables below. >> >> * P9 DD2.2 - 2s * 64 threads >> >> "noirqdebug" >> Mint/s Mint/s >> chips cpus IPI/sys IPI/chip IPI/chip IPI/sys >> -------------------------------------------------------------- >> 1 0-15 4.984023 4.875405 4.996536 5.048892 >> 0-31 10.879164 10.544040 10.757632 11.037859 >> 0-47 15.345301 14.688764 14.926520 15.310053 >> 0-63 17.064907 17.066812 17.613416 17.874511 >> 2 0-79 11.768764 21.650749 22.689120 22.566508 >> 0-95 10.616812 26.878789 28.434703 28.320324 >> 0-111 10.151693 31.397803 31.771773 32.388122 >> 0-127 9.948502 33.139336 34.875716 35.224548 >> >> * P10 DD1 - 4s (not homogeneous) 352 threads >> >> "noirqdebug" >> Mint/s Mint/s >> chips cpus IPI/sys IPI/chip IPI/chip IPI/sys >> -------------------------------------------------------------- >> 1 0-15 2.409402 2.364108 2.383303 2.395091 >> 0-31 6.028325 6.046075 6.089999 6.073750 >> 0-47 8.655178 8.644531 8.712830 8.724702 >> 0-63 11.629652 11.735953 12.088203 12.055979 >> 0-79 14.392321 14.729959 14.986701 14.973073 >> 0-95 12.604158 13.004034 17.528748 17.568095 >> 2 0-111 9.767753 13.719831 19.968606 20.024218 >> 0-127 6.744566 16.418854 22.898066 22.995110 >> 0-143 6.005699 19.174421 25.425622 25.417541 >> 0-159 5.649719 21.938836 27.952662 28.059603 >> 0-175 5.441410 24.109484 31.133915 31.127996 >> 3 0-191 5.318341 24.405322 33.999221 33.775354 >> 0-207 5.191382 26.449769 36.050161 35.867307 >> 0-223 5.102790 29.356943 39.544135 39.508169 >> 0-239 5.035295 31.933051 42.135075 42.071975 >> 0-255 4.969209 34.477367 44.655395 44.757074 >> 4 0-271 4.907652 35.887016 47.080545 47.318537 >> 0-287 4.839581 38.076137 50.464307 50.636219 >> 0-303 4.786031 40.881319 53.478684 53.310759 >> 0-319 4.743750 43.448424 56.388102 55.973969 >> 0-335 4.709936 45.623532 59.400930 58.926857 >> 0-351 4.681413 45.646151 62.035804 61.830057 >> >> [*] https://github.com/antonblanchard/ipistorm >> >> Cc: Thomas Gleixner <tglx@linutronix.de> >> Signed-off-by: Cédric Le Goater <clg@kaod.org> > > Very nice result but the default-on irqdebug code is quite a slowdown > even with your improvements. > > Is the main cacheline bouncing in the fast path coming from > desc->irq_count++ of the percpu handler? Can we do something quick and > dirty like the attached patch? > > All this stuff seems totally racy with percpu handler but maybe that > doesn't matter too much (and anyway it would be a much bigger change) I gave the patch below a try and we are reaching the same results, even better. The simplest solution is always the best. Nick, you should send that single patch. Thanks, C. > Thanks, > Nick > > --- > kernel/irq/spurious.c | 7 ++++++- > 1 file changed, 6 insertions(+), 1 deletion(-) > > diff --git a/kernel/irq/spurious.c b/kernel/irq/spurious.c > index f865e5f4d382..6b17b737ee6c 100644 > --- a/kernel/irq/spurious.c > +++ b/kernel/irq/spurious.c > @@ -378,7 +378,8 @@ void note_interrupt(struct irq_desc *desc, irqreturn_t action_ret) > * then we merily delay the spurious detection > * by one hard interrupt. Not a real problem. > */ > - desc->threads_handled_last &= ~SPURIOUS_DEFERRED; > + if (desc->threads_handled_last & SPURIOUS_DEFERRED) > + desc->threads_handled_last &= ~SPURIOUS_DEFERRED; > } > } > > @@ -403,6 +404,10 @@ void note_interrupt(struct irq_desc *desc, irqreturn_t action_ret) > desc->irqs_unhandled -= ok; > } > > + if (likely(!desc->irqs_unhandled)) > + return; > + > + /* Now getting into unhandled irq detection */ > desc->irq_count++; > if (likely(desc->irq_count < 100000)) > return; >
> I gave the patch below a try and we are reaching the same results, > even better. The simplest solution is always the best. Nick, you > should send that single patch. FYI, here are results in a KVM guests with pinned vCPUs. * P9 DD2.2 - 2s * 64 threads - KVM guest : IPI/sys IPI/chip ----------- -------------------------------- -------------------------------- unhandled unhandled chips cpus noirqdebug detection noirqdebug detection ----------- -------------------------------- -------------------------------- 1 0-15 4.152813 4.084240 4.061028 4.097700 4.042539 4.008314 0-31 8.186328 8.157970 7.937127 8.277942 8.019539 7.831189 0-47 11.391635 11.232960 11.017530 11.278048 10.994501 10.889347 0-63 13.907476 14.022307 11.460280 13.933946 13.506828 11.369188 2 0-79 18.105276 18.084463 8.376047 18.069176 17.587916 15.477006 0-95 22.100683 22.265763 7.338229 22.084006 21.588463 19.502192 0-111 25.305948 25.473068 6.716235 25.429261 24.607570 22.733253 0-127 27.814449 28.029029 6.222736 27.960119 27.253432 23.884916 The three columns "IPI/chip" are results with this series. "IPI/sys" are without. The "unhandled detection" columns are with Nick's patch. C.
diff --git a/arch/powerpc/sysdev/xive/xive-internal.h b/arch/powerpc/sysdev/xive/xive-internal.h index 9cf57c722faa..b3a456fdd3a5 100644 --- a/arch/powerpc/sysdev/xive/xive-internal.h +++ b/arch/powerpc/sysdev/xive/xive-internal.h @@ -5,8 +5,6 @@ #ifndef __XIVE_INTERNAL_H #define __XIVE_INTERNAL_H -#define XIVE_IPI_HW_IRQ 0 /* interrupt source # for IPIs */ - /* * A "disabled" interrupt should never fire, to catch problems * we set its logical number to this diff --git a/arch/powerpc/sysdev/xive/common.c b/arch/powerpc/sysdev/xive/common.c index 69980b49afb7..06f29cd07448 100644 --- a/arch/powerpc/sysdev/xive/common.c +++ b/arch/powerpc/sysdev/xive/common.c @@ -63,8 +63,19 @@ static const struct xive_ops *xive_ops; static struct irq_domain *xive_irq_domain; #ifdef CONFIG_SMP -/* The IPIs all use the same logical irq number */ -static u32 xive_ipi_irq; +/* The IPIs use the same logical irq number when on the same chip */ +static struct xive_ipi_desc { + unsigned int irq; + char name[16]; +} *xive_ipis; + +/* + * Use early_cpu_to_node() for hot-plugged CPUs + */ +static unsigned int xive_ipi_cpu_to_irq(unsigned int cpu) +{ + return xive_ipis[early_cpu_to_node(cpu)].irq; +} #endif /* Xive state for each CPU */ @@ -1107,33 +1118,53 @@ static int __init xive_request_ipi(void) { struct fwnode_handle *fwnode; struct irq_domain *ipi_domain; - unsigned int virq; + unsigned int node; int ret = -ENOMEM; fwnode = irq_domain_alloc_named_fwnode("XIVE-IPI"); if (!fwnode) goto out; - ipi_domain = irq_domain_create_linear(fwnode, 1, + ipi_domain = irq_domain_create_linear(fwnode, nr_node_ids, &xive_ipi_irq_domain_ops, NULL); if (!ipi_domain) goto out_free_fwnode; - /* Initialize it */ - virq = irq_create_mapping(ipi_domain, XIVE_IPI_HW_IRQ); - if (!virq) { - ret = -EINVAL; + xive_ipis = kcalloc(nr_node_ids, sizeof(*xive_ipis), GFP_KERNEL | __GFP_NOFAIL); + if (!xive_ipis) goto out_free_domain; - } - xive_ipi_irq = virq; + for_each_node(node) { + struct xive_ipi_desc *xid = &xive_ipis[node]; + irq_hw_number_t ipi_hwirq = node; + + /* Skip nodes without CPUs */ + if (cpumask_empty(cpumask_of_node(node))) + continue; + + /* + * Map one IPI interrupt per node for all cpus of that node. + * Since the HW interrupt number doesn't have any meaning, + * simply use the node number. + */ + xid->irq = irq_create_mapping(ipi_domain, ipi_hwirq); + if (!xid->irq) { + ret = -EINVAL; + goto out_free_xive_ipis; + } + + snprintf(xid->name, sizeof(xid->name), "IPI-%d", node); + + ret = request_irq(xid->irq, xive_muxed_ipi_action, + IRQF_PERCPU | IRQF_NO_THREAD, xid->name, NULL); - ret = request_irq(virq, xive_muxed_ipi_action, - IRQF_PERCPU | IRQF_NO_THREAD, "IPI", NULL); + WARN(ret < 0, "Failed to request IPI %d: %d\n", xid->irq, ret); + } - WARN(ret < 0, "Failed to request IPI %d: %d\n", virq, ret); return ret; +out_free_xive_ipis: + kfree(xive_ipis); out_free_domain: irq_domain_remove(ipi_domain); out_free_fwnode: @@ -1144,6 +1175,7 @@ static int __init xive_request_ipi(void) static int xive_setup_cpu_ipi(unsigned int cpu) { + unsigned int xive_ipi_irq = xive_ipi_cpu_to_irq(cpu); struct xive_cpu *xc; int rc; @@ -1186,6 +1218,8 @@ static int xive_setup_cpu_ipi(unsigned int cpu) static void xive_cleanup_cpu_ipi(unsigned int cpu, struct xive_cpu *xc) { + unsigned int xive_ipi_irq = xive_ipi_cpu_to_irq(cpu); + /* Disable the IPI and free the IRQ data */ /* Already cleaned up ? */
ipistorm [*] can be used to benchmark the raw interrupt rate of an interrupt controller by measuring the number of IPIs a system can sustain. When applied to the XIVE interrupt controller of POWER9 and POWER10 systems, a significant drop of the interrupt rate can be observed when crossing the second node boundary. This is due to the fact that a single IPI interrupt is used for all CPUs of the system. The structure is shared and the cache line updates impact greatly the traffic between nodes and the overall IPI performance. As a workaround, the impact can be reduced by deactivating the IRQ lockup detector ("noirqdebug") which does a lot of accounting in the Linux IRQ descriptor structure and is responsible for most of the performance penalty. As a fix, this proposal allocates an IPI interrupt per node, to be shared by all CPUs of that node. It solves the scaling issue, the IRQ lockup detector still has an impact but the XIVE interrupt rate scales linearly. It also improves the "noirqdebug" case as showed in the tables below. * P9 DD2.2 - 2s * 64 threads "noirqdebug" Mint/s Mint/s chips cpus IPI/sys IPI/chip IPI/chip IPI/sys -------------------------------------------------------------- 1 0-15 4.984023 4.875405 4.996536 5.048892 0-31 10.879164 10.544040 10.757632 11.037859 0-47 15.345301 14.688764 14.926520 15.310053 0-63 17.064907 17.066812 17.613416 17.874511 2 0-79 11.768764 21.650749 22.689120 22.566508 0-95 10.616812 26.878789 28.434703 28.320324 0-111 10.151693 31.397803 31.771773 32.388122 0-127 9.948502 33.139336 34.875716 35.224548 * P10 DD1 - 4s (not homogeneous) 352 threads "noirqdebug" Mint/s Mint/s chips cpus IPI/sys IPI/chip IPI/chip IPI/sys -------------------------------------------------------------- 1 0-15 2.409402 2.364108 2.383303 2.395091 0-31 6.028325 6.046075 6.089999 6.073750 0-47 8.655178 8.644531 8.712830 8.724702 0-63 11.629652 11.735953 12.088203 12.055979 0-79 14.392321 14.729959 14.986701 14.973073 0-95 12.604158 13.004034 17.528748 17.568095 2 0-111 9.767753 13.719831 19.968606 20.024218 0-127 6.744566 16.418854 22.898066 22.995110 0-143 6.005699 19.174421 25.425622 25.417541 0-159 5.649719 21.938836 27.952662 28.059603 0-175 5.441410 24.109484 31.133915 31.127996 3 0-191 5.318341 24.405322 33.999221 33.775354 0-207 5.191382 26.449769 36.050161 35.867307 0-223 5.102790 29.356943 39.544135 39.508169 0-239 5.035295 31.933051 42.135075 42.071975 0-255 4.969209 34.477367 44.655395 44.757074 4 0-271 4.907652 35.887016 47.080545 47.318537 0-287 4.839581 38.076137 50.464307 50.636219 0-303 4.786031 40.881319 53.478684 53.310759 0-319 4.743750 43.448424 56.388102 55.973969 0-335 4.709936 45.623532 59.400930 58.926857 0-351 4.681413 45.646151 62.035804 61.830057 [*] https://github.com/antonblanchard/ipistorm Cc: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Cédric Le Goater <clg@kaod.org> --- Changes in v3: - increased IPI name length - use of early_cpu_to_node() for hotplugged CPUs - filter CPU-less nodes - dropped Greg's Reviewed-by because of the changes arch/powerpc/sysdev/xive/xive-internal.h | 2 - arch/powerpc/sysdev/xive/common.c | 60 +++++++++++++++++++----- 2 files changed, 47 insertions(+), 15 deletions(-)