From: Jia He <hejianet@gmail.com> To: Thomas Gleixner <tglx@linutronix.de>, Jason Cooper <jason@lakedaemon.net>, Marc Zyngier <marc.zyngier@arm.com> Cc: linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, hejianet@gmail.com, Jia He <jia.he@hxt-semitech.com> Subject: [PATCH] irqchip/gic-v3-its: cap lpi_id_bits to reduce memory footprint Date: Tue, 28 Aug 2018 12:53:26 +0800 [thread overview] Message-ID: <1535432006-2304-1-git-send-email-jia.he@hxt-semitech.com> (raw) 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.000000] GICv3: GIC: Using split EOI/Deactivate mode [ 0.000000] GICv3: Distributor has no Range Selector support [ 0.000000] GICv3: VLPI support, no direct LPI support [ 0.000000] ACPI: SRAT not present [ 0.000000] ITS [mem 0xff7efe0000-0xff7effffff] [ 0.000000] ITS@0x000000ff7efe0000: Using ITS number 0 [ 0.000000] GIC: enabling workaround for ITS: QDF2400 erratum 0065 [ 0.000000] ITS@0x000000ff7efe0000: allocated 524288 Devices @179f000000 (indirect, esz 8, psz 64K, shr 1) [ 0.000000] ITS@0x000000ff7efe0000: allocated 8192 Interrupt Collections @179f930000 (flat, esz 8, psz 64K, shr 1) [ 0.000000] ITS@0x000000ff7efe0000: allocated 65536 Virtual CPUs @179f980000 (flat, esz 8, psz 64K, shr 1) [ 0.000000] WARNING: CPU: 0 PID: 0 at mm/page_alloc.c:4066 __alloc_pages_nodemask+0x2d8/0x1188 [ 0.000000] Modules linked in: [ 0.000000] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.18.0+ #66 [ 0.000000] pstate: 20000085 (nzCv daIf -PAN -UAO) [ 0.000000] pc : __alloc_pages_nodemask+0x2d8/0x1188 [ 0.000000] lr : __alloc_pages_nodemask+0x134/0x1188 [ 0.000000] sp : ffff0000091b3a30 [ 0.000000] x29: ffff0000091b3a30 x28: 0000000000000000 [ 0.000000] x27: ffff00000a045000 x26: 0000000000000000 [ 0.000000] x25: 0000000000000000 x24: ffff0000091c1000 [ 0.000000] x23: ffff0000091b3b98 x22: 000000000000000c [ 0.000000] x21: ffff0000082dc130 x20: 0000000000000001 [ 0.000000] x19: 0000000000000000 x18: 000000000000003f [ 0.000000] x17: 0000000000000000 x16: 0000000000000000 [ 0.000000] x15: ffffffffffffffff x14: 202c74616c662820 [ 0.000000] x13: ffff000009c5f9e0 x12: 0000000000000077 [ 0.000000] x11: 0000000000000078 x10: 0000000097110f47 [ 0.000000] x9 : 0000000000000000 x8 : 00000000009fff3f [ 0.000000] x7 : 000000000000002b x6 : 000000000000000c [ 0.000000] x5 : 0000000000000001 x4 : 0000000000000000 [ 0.000000] x3 : ffff000008fd1000 x2 : ffff000008fd1000 [ 0.000000] x1 : ffff0000091c1000 x0 : 0000000000000000 [ 0.000000] Call trace: [ 0.000000] __alloc_pages_nodemask+0x2d8/0x1188 [ 0.000000] alloc_pages_current+0x8c/0xd8 [ 0.000000] its_allocate_prop_table+0x5c/0xb8 [ 0.000000] its_init+0x220/0x3c0 [ 0.000000] gic_init_bases+0x250/0x380 [ 0.000000] gic_acpi_init+0x16c/0x2a4 [ 0.000000] acpi_match_madt+0x50/0x88 [ 0.000000] acpi_table_parse_entries_array+0x180/0x204 [ 0.000000] acpi_table_parse_entries+0x60/0x84 [ 0.000000] acpi_table_parse_madt+0x40/0x4c [ 0.000000] __acpi_probe_device_table+0x94/0xe8 [ 0.000000] irqchip_init+0x38/0x40 [ 0.000000] init_IRQ+0x70/0x9c [ 0.000000] start_kernel+0x310/0x4c0 [ 0.000000] irq event stamp: 0 [ 0.000000] hardirqs last enabled at (0): [<0000000000000000>] (null) [ 0.000000] hardirqs last disabled at (0): [<0000000000000000>] (null) [ 0.000000] softirqs last enabled at (0): [<0000000000000000>] (null) [ 0.000000] softirqs last disabled at (0): [<0000000000000000>] (null) [ 0.000000] ---[ 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 <jia.he@hxt-semitech.com> Suggested-by: Marc Zyngier <marc.zyngier@arm.com> --- 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
WARNING: multiple messages have this Message-ID (diff)
From: hejianet@gmail.com (Jia He) To: linux-arm-kernel@lists.infradead.org Subject: [PATCH] irqchip/gic-v3-its: cap lpi_id_bits to reduce memory footprint Date: Tue, 28 Aug 2018 12:53:26 +0800 [thread overview] Message-ID: <1535432006-2304-1-git-send-email-jia.he@hxt-semitech.com> (raw) 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.000000] GICv3: GIC: Using split EOI/Deactivate mode [ 0.000000] GICv3: Distributor has no Range Selector support [ 0.000000] GICv3: VLPI support, no direct LPI support [ 0.000000] ACPI: SRAT not present [ 0.000000] ITS [mem 0xff7efe0000-0xff7effffff] [ 0.000000] ITS at 0x000000ff7efe0000: Using ITS number 0 [ 0.000000] GIC: enabling workaround for ITS: QDF2400 erratum 0065 [ 0.000000] ITS at 0x000000ff7efe0000: allocated 524288 Devices @179f000000 (indirect, esz 8, psz 64K, shr 1) [ 0.000000] ITS at 0x000000ff7efe0000: allocated 8192 Interrupt Collections @179f930000 (flat, esz 8, psz 64K, shr 1) [ 0.000000] ITS at 0x000000ff7efe0000: allocated 65536 Virtual CPUs @179f980000 (flat, esz 8, psz 64K, shr 1) [ 0.000000] WARNING: CPU: 0 PID: 0 at mm/page_alloc.c:4066 __alloc_pages_nodemask+0x2d8/0x1188 [ 0.000000] Modules linked in: [ 0.000000] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.18.0+ #66 [ 0.000000] pstate: 20000085 (nzCv daIf -PAN -UAO) [ 0.000000] pc : __alloc_pages_nodemask+0x2d8/0x1188 [ 0.000000] lr : __alloc_pages_nodemask+0x134/0x1188 [ 0.000000] sp : ffff0000091b3a30 [ 0.000000] x29: ffff0000091b3a30 x28: 0000000000000000 [ 0.000000] x27: ffff00000a045000 x26: 0000000000000000 [ 0.000000] x25: 0000000000000000 x24: ffff0000091c1000 [ 0.000000] x23: ffff0000091b3b98 x22: 000000000000000c [ 0.000000] x21: ffff0000082dc130 x20: 0000000000000001 [ 0.000000] x19: 0000000000000000 x18: 000000000000003f [ 0.000000] x17: 0000000000000000 x16: 0000000000000000 [ 0.000000] x15: ffffffffffffffff x14: 202c74616c662820 [ 0.000000] x13: ffff000009c5f9e0 x12: 0000000000000077 [ 0.000000] x11: 0000000000000078 x10: 0000000097110f47 [ 0.000000] x9 : 0000000000000000 x8 : 00000000009fff3f [ 0.000000] x7 : 000000000000002b x6 : 000000000000000c [ 0.000000] x5 : 0000000000000001 x4 : 0000000000000000 [ 0.000000] x3 : ffff000008fd1000 x2 : ffff000008fd1000 [ 0.000000] x1 : ffff0000091c1000 x0 : 0000000000000000 [ 0.000000] Call trace: [ 0.000000] __alloc_pages_nodemask+0x2d8/0x1188 [ 0.000000] alloc_pages_current+0x8c/0xd8 [ 0.000000] its_allocate_prop_table+0x5c/0xb8 [ 0.000000] its_init+0x220/0x3c0 [ 0.000000] gic_init_bases+0x250/0x380 [ 0.000000] gic_acpi_init+0x16c/0x2a4 [ 0.000000] acpi_match_madt+0x50/0x88 [ 0.000000] acpi_table_parse_entries_array+0x180/0x204 [ 0.000000] acpi_table_parse_entries+0x60/0x84 [ 0.000000] acpi_table_parse_madt+0x40/0x4c [ 0.000000] __acpi_probe_device_table+0x94/0xe8 [ 0.000000] irqchip_init+0x38/0x40 [ 0.000000] init_IRQ+0x70/0x9c [ 0.000000] start_kernel+0x310/0x4c0 [ 0.000000] irq event stamp: 0 [ 0.000000] hardirqs last enabled at (0): [<0000000000000000>] (null) [ 0.000000] hardirqs last disabled at (0): [<0000000000000000>] (null) [ 0.000000] softirqs last enabled at (0): [<0000000000000000>] (null) [ 0.000000] softirqs last disabled at (0): [<0000000000000000>] (null) [ 0.000000] ---[ 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 <jia.he@hxt-semitech.com> Suggested-by: Marc Zyngier <marc.zyngier@arm.com> --- 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
next reply other threads:[~2018-08-28 4:54 UTC|newest] Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-08-28 4:53 Jia He [this message] 2018-08-28 4:53 ` [PATCH] irqchip/gic-v3-its: cap lpi_id_bits to reduce memory footprint Jia He 2018-08-28 8:58 ` Marc Zyngier 2018-08-28 8:58 ` Marc Zyngier 2018-08-28 12:08 ` Jia He 2018-08-28 12:08 ` Jia He 2018-08-31 15:38 ` Olof Johansson 2018-08-31 15:38 ` Olof Johansson 2018-09-06 18:36 ` [tip:irq/urgent] irqchip/gic-v3-its: Cap " tip-bot for Jia He
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=1535432006-2304-1-git-send-email-jia.he@hxt-semitech.com \ --to=hejianet@gmail.com \ --cc=jason@lakedaemon.net \ --cc=jia.he@hxt-semitech.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=marc.zyngier@arm.com \ --cc=tglx@linutronix.de \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.