From: Marc Zyngier <marc.zyngier@arm.com>
To: Shanker Donthineni <shankerd@codeaurora.org>
Cc: Thomas Gleixner <tglx@linutronix.de>,
Jason Cooper <jason@lakedaemon.net>,
linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
linux-kernel <linux-kernel@vger.kernel.org>,
Vikram Sethi <vikrams@codeaurora.org>
Subject: Re: [PATCH v3] irqchip/gicv3-its: Avoid memory over allocation for ITEs
Date: Fri, 17 Mar 2017 13:50:39 +0000 [thread overview]
Message-ID: <b74f8fbb-0d9a-b1e2-83d2-ba9c1a858222@arm.com> (raw)
In-Reply-To: <1488896720-6223-1-git-send-email-shankerd@codeaurora.org>
On 07/03/17 14:25, Shanker Donthineni wrote:
> We are always allocating extra 255Bytes of memory to handle ITE
> physical address alignment requirement. The kmalloc() satisfies
> the ITE alignment since the ITS driver is requesting a minimum
> size of ITS_ITT_ALIGN bytes.
>
> Let's try to allocate the exact amount of memory that is required
> for ITEs to avoid wastage.
>
> Signed-off-by: Shanker Donthineni <shankerd@codeaurora.org>
> ---
> v2: removed 'Change-Id: Ia8084189833f2081ff13c392deb5070c46a64038' from commit.
> v3: changed from IITE to ITE.
>
> drivers/irqchip/irq-gic-v3-its.c | 7 ++++++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
> index 86bd428..5aeca78 100644
> --- a/drivers/irqchip/irq-gic-v3-its.c
> +++ b/drivers/irqchip/irq-gic-v3-its.c
> @@ -1329,8 +1329,13 @@ static struct its_device *its_create_device(struct its_node *its, u32 dev_id,
> */
> nr_ites = max(2UL, roundup_pow_of_two(nvecs));
> sz = nr_ites * its->ite_size;
> - sz = max(sz, ITS_ITT_ALIGN) + ITS_ITT_ALIGN - 1;
> + sz = max(sz, ITS_ITT_ALIGN);
> itt = kzalloc(sz, GFP_KERNEL);
> + if (itt && !IS_ALIGNED(virt_to_phys(itt), ITS_ITT_ALIGN)) {
> + kfree(itt);
> + itt = kzalloc(sz + ITS_ITT_ALIGN - 1, GFP_KERNEL);
> + }
> +
Is this really worth the complexity? Are you aware of a system where the
accumulation of overallocation actually shows up as being an issue?
If you want to be absolutely exact in your allocation, then I'd suggest
doing it all the time, and have a proper dedicated allocator that always
do the right thing, without a wasteful fallback like you still have here.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
next prev parent reply other threads:[~2017-03-17 13:50 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-07 14:25 [PATCH v3] irqchip/gicv3-its: Avoid memory over allocation for ITEs Shanker Donthineni
2017-03-17 13:50 ` Marc Zyngier [this message]
2017-03-17 14:18 ` Shanker Donthineni
2017-03-17 15:33 ` Marc Zyngier
2017-03-20 10:14 ` Shanker Donthineni
2017-03-20 11:15 ` Shanker Donthineni
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=b74f8fbb-0d9a-b1e2-83d2-ba9c1a858222@arm.com \
--to=marc.zyngier@arm.com \
--cc=jason@lakedaemon.net \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=shankerd@codeaurora.org \
--cc=tglx@linutronix.de \
--cc=vikrams@codeaurora.org \
/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: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox