Re: [PATCH] irqchip/gic-v3-its: cap lpi_id_bits to reduce memory footprint
On Tue, Aug 28, 2018 at 1:58 AM, Marc Zyngier wrote: > On Tue, 28 Aug 2018 05:53:26 +0100, > Jia He wrote: >> >> In commit fe8e93504ce8 ("irqchip/gic-v3-its: Use full range of LPIs"), >> it removes the cap for lpi_id_bits. But it will cause more pointless >> memory footprint. >> >> There is a WARN_ON when my QDF2400 server boots up (pagesize is 4k) >> begin=== > > [trimming not-so-useful trace] > >> end >> >> In its_alloc_lpi_tables, lpi_id_bits is 24 in QDF2400. Then >> its_allocate_prop_table will try to allocate 16M(order 12 if >> pagesize=4k). Thus it causes the WARN_ON. >> >> As said by Marc, >> Capping lpi_id_bits at 16 (which is what we had before) is plenty, >> will save a some memory, and gives some margin before we need to push >> it up again. >> >> This patch re-caps the lpi_id_bits. >> >> Fixes: fe8e93504ce8 ("irqchip/gic-v3-its: Use full range of LPIs") >> Signed-off-by: Jia He >> Suggested-by: Marc Zyngier > > Thanks for doing this. Small problem with this patch: > > The email comes from hejia...@gmail.com, while the sign off is by > jia...@hxt-semitech.com. Your email should start with a: > > From: Jia He > > Other than that: > > Acked-by: Marc Zyngier Tested-by: Olof Johansson > Thomas, would you mind picking this up so that it gets into the next > convenient -rc? Yeah, it'd be great to see this go into -rc2 if possible. Thanks! -Olof
Re: [PATCH] irqchip/gic-v3-its: cap lpi_id_bits to reduce memory footprint
On Tue, Aug 28, 2018 at 1:58 AM, Marc Zyngier wrote: > On Tue, 28 Aug 2018 05:53:26 +0100, > Jia He wrote: >> >> In commit fe8e93504ce8 ("irqchip/gic-v3-its: Use full range of LPIs"), >> it removes the cap for lpi_id_bits. But it will cause more pointless >> memory footprint. >> >> There is a WARN_ON when my QDF2400 server boots up (pagesize is 4k) >> begin=== > > [trimming not-so-useful trace] > >> end >> >> In its_alloc_lpi_tables, lpi_id_bits is 24 in QDF2400. Then >> its_allocate_prop_table will try to allocate 16M(order 12 if >> pagesize=4k). Thus it causes the WARN_ON. >> >> As said by Marc, >> Capping lpi_id_bits at 16 (which is what we had before) is plenty, >> will save a some memory, and gives some margin before we need to push >> it up again. >> >> This patch re-caps the lpi_id_bits. >> >> Fixes: fe8e93504ce8 ("irqchip/gic-v3-its: Use full range of LPIs") >> Signed-off-by: Jia He >> Suggested-by: Marc Zyngier > > Thanks for doing this. Small problem with this patch: > > The email comes from hejia...@gmail.com, while the sign off is by > jia...@hxt-semitech.com. Your email should start with a: > > From: Jia He > > Other than that: > > Acked-by: Marc Zyngier Tested-by: Olof Johansson > Thomas, would you mind picking this up so that it gets into the next > convenient -rc? Yeah, it'd be great to see this go into -rc2 if possible. Thanks! -Olof
Re: [PATCH] irqchip/gic-v3-its: cap lpi_id_bits to reduce memory footprint
On 8/28/2018 4:58 PM, Marc Zyngier Wrote: > On Tue, 28 Aug 2018 05:53:26 +0100, > Jia He wrote: >> >> In commit fe8e93504ce8 ("irqchip/gic-v3-its: Use full range of LPIs"), >> it removes the cap for lpi_id_bits. But it will cause more pointless >> memory footprint. >> >> There is a WARN_ON when my QDF2400 server boots up (pagesize is 4k) >> begin=== > > [trimming not-so-useful trace] > >> end >> >> In its_alloc_lpi_tables, lpi_id_bits is 24 in QDF2400. Then >> its_allocate_prop_table will try to allocate 16M(order 12 if >> pagesize=4k). Thus it causes the WARN_ON. >> >> As said by Marc, >> Capping lpi_id_bits at 16 (which is what we had before) is plenty, >> will save a some memory, and gives some margin before we need to push >> it up again. >> >> This patch re-caps the lpi_id_bits. >> >> Fixes: fe8e93504ce8 ("irqchip/gic-v3-its: Use full range of LPIs") >> Signed-off-by: Jia He >> Suggested-by: Marc Zyngier > > Thanks for doing this. Small problem with this patch: > > The email comes from hejia...@gmail.com, while the sign off is by > jia...@hxt-semitech.com. Your email should start with a: > > From: Jia He > Thanks for the pointing. And sorry for that problem. --- Cheers, Jia > Other than that: > > Acked-by: Marc Zyngier > > Thomas, would you mind picking this up so that it gets into the next > convenient -rc? > > Thanks, > > M. (/me goes back hiking...) > >
Re: [PATCH] irqchip/gic-v3-its: cap lpi_id_bits to reduce memory footprint
On 8/28/2018 4:58 PM, Marc Zyngier Wrote: > On Tue, 28 Aug 2018 05:53:26 +0100, > Jia He wrote: >> >> In commit fe8e93504ce8 ("irqchip/gic-v3-its: Use full range of LPIs"), >> it removes the cap for lpi_id_bits. But it will cause more pointless >> memory footprint. >> >> There is a WARN_ON when my QDF2400 server boots up (pagesize is 4k) >> begin=== > > [trimming not-so-useful trace] > >> end >> >> In its_alloc_lpi_tables, lpi_id_bits is 24 in QDF2400. Then >> its_allocate_prop_table will try to allocate 16M(order 12 if >> pagesize=4k). Thus it causes the WARN_ON. >> >> As said by Marc, >> Capping lpi_id_bits at 16 (which is what we had before) is plenty, >> will save a some memory, and gives some margin before we need to push >> it up again. >> >> This patch re-caps the lpi_id_bits. >> >> Fixes: fe8e93504ce8 ("irqchip/gic-v3-its: Use full range of LPIs") >> Signed-off-by: Jia He >> Suggested-by: Marc Zyngier > > Thanks for doing this. Small problem with this patch: > > The email comes from hejia...@gmail.com, while the sign off is by > jia...@hxt-semitech.com. Your email should start with a: > > From: Jia He > Thanks for the pointing. And sorry for that problem. --- Cheers, Jia > Other than that: > > Acked-by: Marc Zyngier > > Thomas, would you mind picking this up so that it gets into the next > convenient -rc? > > Thanks, > > M. (/me goes back hiking...) > >
Re: [PATCH] irqchip/gic-v3-its: cap lpi_id_bits to reduce memory footprint
On Tue, 28 Aug 2018 05:53:26 +0100, Jia He wrote: > > In commit fe8e93504ce8 ("irqchip/gic-v3-its: Use full range of LPIs"), > it removes the cap for lpi_id_bits. But it will cause more pointless > memory footprint. > > There is a WARN_ON when my QDF2400 server boots up (pagesize is 4k) > begin=== [trimming not-so-useful trace] > end > > In its_alloc_lpi_tables, lpi_id_bits is 24 in QDF2400. Then > its_allocate_prop_table will try to allocate 16M(order 12 if > pagesize=4k). Thus it causes the WARN_ON. > > As said by Marc, > Capping lpi_id_bits at 16 (which is what we had before) is plenty, > will save a some memory, and gives some margin before we need to push > it up again. > > This patch re-caps the lpi_id_bits. > > Fixes: fe8e93504ce8 ("irqchip/gic-v3-its: Use full range of LPIs") > Signed-off-by: Jia He > Suggested-by: Marc Zyngier Thanks for doing this. Small problem with this patch: The email comes from hejia...@gmail.com, while the sign off is by jia...@hxt-semitech.com. Your email should start with a: From: Jia He Other than that: Acked-by: Marc Zyngier Thomas, would you mind picking this up so that it gets into the next convenient -rc? Thanks, M. (/me goes back hiking...) -- Jazz is not dead, it just smell funny.
Re: [PATCH] irqchip/gic-v3-its: cap lpi_id_bits to reduce memory footprint
On Tue, 28 Aug 2018 05:53:26 +0100, Jia He wrote: > > In commit fe8e93504ce8 ("irqchip/gic-v3-its: Use full range of LPIs"), > it removes the cap for lpi_id_bits. But it will cause more pointless > memory footprint. > > There is a WARN_ON when my QDF2400 server boots up (pagesize is 4k) > begin=== [trimming not-so-useful trace] > end > > In its_alloc_lpi_tables, lpi_id_bits is 24 in QDF2400. Then > its_allocate_prop_table will try to allocate 16M(order 12 if > pagesize=4k). Thus it causes the WARN_ON. > > As said by Marc, > Capping lpi_id_bits at 16 (which is what we had before) is plenty, > will save a some memory, and gives some margin before we need to push > it up again. > > This patch re-caps the lpi_id_bits. > > Fixes: fe8e93504ce8 ("irqchip/gic-v3-its: Use full range of LPIs") > Signed-off-by: Jia He > Suggested-by: Marc Zyngier Thanks for doing this. Small problem with this patch: The email comes from hejia...@gmail.com, while the sign off is by jia...@hxt-semitech.com. Your email should start with a: From: Jia He Other than that: Acked-by: Marc Zyngier Thomas, would you mind picking this up so that it gets into the next convenient -rc? Thanks, M. (/me goes back hiking...) -- Jazz is not dead, it just smell funny.
[PATCH] irqchip/gic-v3-its: cap lpi_id_bits to reduce memory footprint
In commit fe8e93504ce8 ("irqchip/gic-v3-its: Use full range of LPIs"), it removes the cap for lpi_id_bits. But it will cause more pointless memory footprint. There is a WARN_ON when my QDF2400 server boots up (pagesize is 4k) begin=== [0.00] GICv3: GIC: Using split EOI/Deactivate mode [0.00] GICv3: Distributor has no Range Selector support [0.00] GICv3: VLPI support, no direct LPI support [0.00] ACPI: SRAT not present [0.00] ITS [mem 0xff7efe-0xff7eff] [0.00] ITS@0x00ff7efe: Using ITS number 0 [0.00] GIC: enabling workaround for ITS: QDF2400 erratum 0065 [0.00] ITS@0x00ff7efe: allocated 524288 Devices @179f00 (indirect, esz 8, psz 64K, shr 1) [0.00] ITS@0x00ff7efe: allocated 8192 Interrupt Collections @179f93 (flat, esz 8, psz 64K, shr 1) [0.00] ITS@0x00ff7efe: allocated 65536 Virtual CPUs @179f98 (flat, esz 8, psz 64K, shr 1) [0.00] WARNING: CPU: 0 PID: 0 at mm/page_alloc.c:4066 __alloc_pages_nodemask+0x2d8/0x1188 [0.00] Modules linked in: [0.00] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.18.0+ #66 [0.00] pstate: 2085 (nzCv daIf -PAN -UAO) [0.00] pc : __alloc_pages_nodemask+0x2d8/0x1188 [0.00] lr : __alloc_pages_nodemask+0x134/0x1188 [0.00] sp : 091b3a30 [0.00] x29: 091b3a30 x28: [0.00] x27: 0a045000 x26: [0.00] x25: x24: 091c1000 [0.00] x23: 091b3b98 x22: 000c [0.00] x21: 082dc130 x20: 0001 [0.00] x19: x18: 003f [0.00] x17: x16: [0.00] x15: x14: 202c74616c662820 [0.00] x13: 09c5f9e0 x12: 0077 [0.00] x11: 0078 x10: 97110f47 [0.00] x9 : x8 : 009fff3f [0.00] x7 : 002b x6 : 000c [0.00] x5 : 0001 x4 : [0.00] x3 : 08fd1000 x2 : 08fd1000 [0.00] x1 : 091c1000 x0 : [0.00] Call trace: [0.00] __alloc_pages_nodemask+0x2d8/0x1188 [0.00] alloc_pages_current+0x8c/0xd8 [0.00] its_allocate_prop_table+0x5c/0xb8 [0.00] its_init+0x220/0x3c0 [0.00] gic_init_bases+0x250/0x380 [0.00] gic_acpi_init+0x16c/0x2a4 [0.00] acpi_match_madt+0x50/0x88 [0.00] acpi_table_parse_entries_array+0x180/0x204 [0.00] acpi_table_parse_entries+0x60/0x84 [0.00] acpi_table_parse_madt+0x40/0x4c [0.00] __acpi_probe_device_table+0x94/0xe8 [0.00] irqchip_init+0x38/0x40 [0.00] init_IRQ+0x70/0x9c [0.00] start_kernel+0x310/0x4c0 [0.00] irq event stamp: 0 [0.00] hardirqs last enabled at (0): [<>] (null) [0.00] hardirqs last disabled at (0): [<>] (null) [0.00] softirqs last enabled at (0): [<>] (null) [0.00] softirqs last disabled at (0): [<>] (null) [0.00] ---[ end trace 943781056d97862b ]--- end In its_alloc_lpi_tables, lpi_id_bits is 24 in QDF2400. Then its_allocate_prop_table will try to allocate 16M(order 12 if pagesize=4k). Thus it causes the WARN_ON. As said by Marc, Capping lpi_id_bits at 16 (which is what we had before) is plenty, will save a some memory, and gives some margin before we need to push it up again. This patch re-caps the lpi_id_bits. Fixes: fe8e93504ce8 ("irqchip/gic-v3-its: Use full range of LPIs") Signed-off-by: Jia He Suggested-by: Marc Zyngier --- drivers/irqchip/irq-gic-v3-its.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c index 316a575..c2df341 100644 --- a/drivers/irqchip/irq-gic-v3-its.c +++ b/drivers/irqchip/irq-gic-v3-its.c @@ -1439,6 +1439,7 @@ static int its_irq_set_vcpu_affinity(struct irq_data *d, void *vcpu_info) * The consequence of the above is that allocation is cost is low, but * freeing is expensive. We assumes that freeing rarely occurs. */ +#define ITS_MAX_LPI_NRBITS 16 /* 64K LPIs */ static DEFINE_MUTEX(lpi_range_lock); static LIST_HEAD(lpi_range_list); @@ -1625,7 +1626,8 @@ static int __init its_alloc_lpi_tables(void) { phys_addr_t paddr; - lpi_id_bits = GICD_TYPER_ID_BITS(gic_rdists->gicd_typer); + lpi_id_bits = min_t(u32, GICD_TYPER_ID_BITS(gic_rdists->gicd_typer), + ITS_MAX_LPI_NRBITS); gic_rdists->prop_page = its_allocate_prop_table(GFP_NOWAIT); if (!gic_rdists->prop_page) { pr_err("Failed to allocate PROPBASE\n"); -- 1.8.3.1
[PATCH] irqchip/gic-v3-its: cap lpi_id_bits to reduce memory footprint
In commit fe8e93504ce8 ("irqchip/gic-v3-its: Use full range of LPIs"), it removes the cap for lpi_id_bits. But it will cause more pointless memory footprint. There is a WARN_ON when my QDF2400 server boots up (pagesize is 4k) begin=== [0.00] GICv3: GIC: Using split EOI/Deactivate mode [0.00] GICv3: Distributor has no Range Selector support [0.00] GICv3: VLPI support, no direct LPI support [0.00] ACPI: SRAT not present [0.00] ITS [mem 0xff7efe-0xff7eff] [0.00] ITS@0x00ff7efe: Using ITS number 0 [0.00] GIC: enabling workaround for ITS: QDF2400 erratum 0065 [0.00] ITS@0x00ff7efe: allocated 524288 Devices @179f00 (indirect, esz 8, psz 64K, shr 1) [0.00] ITS@0x00ff7efe: allocated 8192 Interrupt Collections @179f93 (flat, esz 8, psz 64K, shr 1) [0.00] ITS@0x00ff7efe: allocated 65536 Virtual CPUs @179f98 (flat, esz 8, psz 64K, shr 1) [0.00] WARNING: CPU: 0 PID: 0 at mm/page_alloc.c:4066 __alloc_pages_nodemask+0x2d8/0x1188 [0.00] Modules linked in: [0.00] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.18.0+ #66 [0.00] pstate: 2085 (nzCv daIf -PAN -UAO) [0.00] pc : __alloc_pages_nodemask+0x2d8/0x1188 [0.00] lr : __alloc_pages_nodemask+0x134/0x1188 [0.00] sp : 091b3a30 [0.00] x29: 091b3a30 x28: [0.00] x27: 0a045000 x26: [0.00] x25: x24: 091c1000 [0.00] x23: 091b3b98 x22: 000c [0.00] x21: 082dc130 x20: 0001 [0.00] x19: x18: 003f [0.00] x17: x16: [0.00] x15: x14: 202c74616c662820 [0.00] x13: 09c5f9e0 x12: 0077 [0.00] x11: 0078 x10: 97110f47 [0.00] x9 : x8 : 009fff3f [0.00] x7 : 002b x6 : 000c [0.00] x5 : 0001 x4 : [0.00] x3 : 08fd1000 x2 : 08fd1000 [0.00] x1 : 091c1000 x0 : [0.00] Call trace: [0.00] __alloc_pages_nodemask+0x2d8/0x1188 [0.00] alloc_pages_current+0x8c/0xd8 [0.00] its_allocate_prop_table+0x5c/0xb8 [0.00] its_init+0x220/0x3c0 [0.00] gic_init_bases+0x250/0x380 [0.00] gic_acpi_init+0x16c/0x2a4 [0.00] acpi_match_madt+0x50/0x88 [0.00] acpi_table_parse_entries_array+0x180/0x204 [0.00] acpi_table_parse_entries+0x60/0x84 [0.00] acpi_table_parse_madt+0x40/0x4c [0.00] __acpi_probe_device_table+0x94/0xe8 [0.00] irqchip_init+0x38/0x40 [0.00] init_IRQ+0x70/0x9c [0.00] start_kernel+0x310/0x4c0 [0.00] irq event stamp: 0 [0.00] hardirqs last enabled at (0): [<>] (null) [0.00] hardirqs last disabled at (0): [<>] (null) [0.00] softirqs last enabled at (0): [<>] (null) [0.00] softirqs last disabled at (0): [<>] (null) [0.00] ---[ end trace 943781056d97862b ]--- end In its_alloc_lpi_tables, lpi_id_bits is 24 in QDF2400. Then its_allocate_prop_table will try to allocate 16M(order 12 if pagesize=4k). Thus it causes the WARN_ON. As said by Marc, Capping lpi_id_bits at 16 (which is what we had before) is plenty, will save a some memory, and gives some margin before we need to push it up again. This patch re-caps the lpi_id_bits. Fixes: fe8e93504ce8 ("irqchip/gic-v3-its: Use full range of LPIs") Signed-off-by: Jia He Suggested-by: Marc Zyngier --- drivers/irqchip/irq-gic-v3-its.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c index 316a575..c2df341 100644 --- a/drivers/irqchip/irq-gic-v3-its.c +++ b/drivers/irqchip/irq-gic-v3-its.c @@ -1439,6 +1439,7 @@ static int its_irq_set_vcpu_affinity(struct irq_data *d, void *vcpu_info) * The consequence of the above is that allocation is cost is low, but * freeing is expensive. We assumes that freeing rarely occurs. */ +#define ITS_MAX_LPI_NRBITS 16 /* 64K LPIs */ static DEFINE_MUTEX(lpi_range_lock); static LIST_HEAD(lpi_range_list); @@ -1625,7 +1626,8 @@ static int __init its_alloc_lpi_tables(void) { phys_addr_t paddr; - lpi_id_bits = GICD_TYPER_ID_BITS(gic_rdists->gicd_typer); + lpi_id_bits = min_t(u32, GICD_TYPER_ID_BITS(gic_rdists->gicd_typer), + ITS_MAX_LPI_NRBITS); gic_rdists->prop_page = its_allocate_prop_table(GFP_NOWAIT); if (!gic_rdists->prop_page) { pr_err("Failed to allocate PROPBASE\n"); -- 1.8.3.1