mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Marc Zyngier <marc.zyngier@arm.com>
To: shankerd@codeaurora.org, Ganapatrao Kulkarni <gpkulkarni@gmail.com>
Cc: linux-kernel <linux-kernel@vger.kernel.org>,
	linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Jason Cooper <jason@lakedaemon.net>,
	Vikram Sethi <vikrams@codeaurora.org>,
	Jayachandran C <jnair@caviumnetworks.com>,
	"ganapatrao.kulkarni@cavium.com" <ganapatrao.kulkarni@cavium.com>
Subject: Re: [PATCH] irqchip: gicv3-its: Use NUMA aware memory allocation for ITS tables
Date: Mon, 3 Jul 2017 15:53:49 +0100	[thread overview]
Message-ID: <27b46938-ae23-9750-e0c7-09fa472d3297@arm.com> (raw)
In-Reply-To: <ba64069e-f3a3-de85-df47-01008d7b3513@codeaurora.org>

Hi Shanker,

On 03/07/17 15:24, Shanker Donthineni wrote:
> Hi Marc,
> 
> On 06/30/2017 03:51 AM, Marc Zyngier wrote:
>> On 30/06/17 04:01, Ganapatrao Kulkarni wrote:
>>> On Fri, Jun 30, 2017 at 8:04 AM, Ganapatrao Kulkarni
>>> <gpkulkarni@gmail.com> wrote:
>>>> Hi Shanker,
>>>>
>>>> On Sun, Jun 25, 2017 at 9:16 PM, Shanker Donthineni
>>>> <shankerd@codeaurora.org> wrote:
>>>>> The NUMA node information is visible to ITS driver but not being used
>>>>> other than handling errata. This patch allocates the memory for ITS
>>>>> tables from the corresponding NUMA node using the appropriate NUMA
>>>>> aware functions.
>>>
>>> IMHO, the description would have been more constructive?
>>>
>>> "All ITS tables are mapped by default to NODE 0 memory.
>>> Adding changes to allocate memory from respective NUMA NODES of ITS devices.
>>> This will optimize tables access and avoids unnecessary inter-node traffic."
>>
>> But more importantly, I'd like to see figures showing the actual benefit
>> of this per-node allocation. Given that both of you guys have access to
>> such platforms, please show me the numbers!
>>
> 
> I'll share the actual results which shows the improvement whenever 
> available on our next chips. Current version of Qualcomm qdf2400 doesn't 
> support multi socket configuration to capture results and share with you. 
> 
> Do you see any other issues with this patch apart from the performance 
> improvements. I strongly believe this brings the noticeable improvement 
> in numbers on systems where it has multi node memory/CPU configuration.

I agree that it *could* show an improvement, but it very much depends on
how often the ITS misses in its caches. For this kind of patches, I want
to see two things:

1) It brings a measurable benefit on NUMA platforms
2) it doesn't adversely impact non-NUMA systems

I can deal with (2), but I have no way of evaluating (1), mostly for the
lack of an infrastructure exercising multiple ITSs at the same time.

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...

  reply	other threads:[~2017-07-03 14:53 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-25 15:46 Shanker Donthineni
2017-06-30  2:34 ` Ganapatrao Kulkarni
2017-06-30  3:01   ` Ganapatrao Kulkarni
2017-06-30  8:51     ` Marc Zyngier
2017-07-03 14:24       ` Shanker Donthineni
2017-07-03 14:53         ` Marc Zyngier [this message]
2017-07-03 15:15           ` Shanker Donthineni
2017-07-10  8:48           ` Ganapatrao Kulkarni
2017-07-10  9:06             ` Marc Zyngier
2017-07-10  9:08               ` Ganapatrao Kulkarni
2017-07-10  9:23                 ` Marc Zyngier
2017-07-10 10:21                   ` Ganapatrao Kulkarni
2017-07-10 12:30                     ` Shanker Donthineni
2017-07-10 13:53                       ` Marc Zyngier
2017-07-10 13:50                     ` Marc Zyngier
2017-07-10 14:57                       ` Shanker Donthineni
2017-07-10 15:15                         ` Marc Zyngier
2017-07-11  8:48                           ` Jayachandran C
2017-07-13 15:40                             ` Robert Richter

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=27b46938-ae23-9750-e0c7-09fa472d3297@arm.com \
    --to=marc.zyngier@arm.com \
    --cc=ganapatrao.kulkarni@cavium.com \
    --cc=gpkulkarni@gmail.com \
    --cc=jason@lakedaemon.net \
    --cc=jnair@caviumnetworks.com \
    --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

all inboxes | Powered by JetHome®