From: Marc Zyngier <marc.zyngier@arm.com>
To: "majun (Euler7)" <majun258@huawei.com>,
linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org,
robert.moore@intel.com, lenb@kernel.org, lv.zheng@intel.com,
rafael.j.wysocki@intel.com, devel@acpica.org,
mark.rutland@arm.com, robh+dt@kernel.org, jason@lakedaemon.net
Cc: dingtianhong@huawei.com, guohanjun@huawei.com
Subject: Re: [RFC PATCH 0/3] Add a new flag for ITS device to control indirect route
Date: Mon, 5 Dec 2016 09:00:38 +0000 [thread overview]
Message-ID: <529ccaef-32e5-03cc-9947-d5803650a276@arm.com> (raw)
In-Reply-To: <5844DAE0.9050101@huawei.com>
On 05/12/16 03:11, majun (Euler7) wrote:
> Hi Marc:
>
> 在 2016/12/2 17:35, Marc Zyngier 写道:
>> On 02/12/16 09:29, majun (Euler7) wrote:
>>>
>>>
>>> 在 2016/12/1 17:07, Marc Zyngier 写道:
>>>> On 01/12/16 07:45, Majun wrote:
>>>>> From: MaJun <majun258@huawei.com>
>>>>>
>>>>> For current ITS driver, two level table (indirect route) is enabled when the memory used
>>>>> for LPI route table over the limit(64KB * 2) size. But this function impact the
>>>>> performance of LPI interrupt actually because need more time to look up the table.
>>>>
>>>> Are you implying that your ITS doesn't have a cache to lookup the most
>>>> active devices, hence performing a full lookup on each interrupt?
>>>
>>> Our ITS chip has the cache with depth 64. But this seems not enough for some
>>> scenario,espeically on virtulization platform.
>>
>> Then I don't see how switching to to flat tables is going to improve
>> things. Can you share actual performance numbers?
>>
> Sorry, I run this code on EMU and have no actual performance numbers now.
So how can you make a decision on what is obviously an optimization for
a given use case?
> Suppose there are 66 devices in system.
> As far as our chip concerned, there are always 2 devices can't benefit from
> cache fully when they report the interrupt.
>
> If i'm wrong, please correct me.
Congratulations, you've just discovered one the limitations of *any*
cache. If your miss rate is too high, then your cache is too small (or
your replacement policy is suboptimal). Switching to flat tables is
going to slightly reduce the miss latency (one read less), but is not
going to improve the miss rate.
I'd suggest you talk to your HW people so that they give you either a
bigger cache or a better replacement policy. Or even put fewer devices
in front of your ITS so that you won't miss in the cache, assuming that
your interrupt latency is so critical that you can't miss once in a
while (which I very seriously doubt).
Thanks,
M.
--
Jazz is not dead. It just smells funny...
prev parent reply other threads:[~2016-12-05 9:01 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-12-01 7:45 Majun
2016-12-01 7:45 ` [RFC PATCH 1/3]Binding: Add a new property string in ITS node to control the two-level route function Majun
2016-12-01 7:45 ` [RFC PATCH 2/3] irqchip/gicv3-its: add a new flag to control indirect route in DT mode Majun
2016-12-01 7:46 ` [RFC PATCH 3/3]irqchip/gicv3-its: Add a new flag to control indirect route in ACPI mode Majun
2016-12-01 9:07 ` [RFC PATCH 0/3] Add a new flag for ITS device to control indirect route Marc Zyngier
2016-12-02 9:29 ` majun (Euler7)
2016-12-02 9:35 ` Marc Zyngier
2016-12-05 3:11 ` majun (Euler7)
2016-12-05 9:00 ` Marc Zyngier [this message]
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=529ccaef-32e5-03cc-9947-d5803650a276@arm.com \
--to=marc.zyngier@arm.com \
--cc=devel@acpica.org \
--cc=dingtianhong@huawei.com \
--cc=guohanjun@huawei.com \
--cc=jason@lakedaemon.net \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lv.zheng@intel.com \
--cc=majun258@huawei.com \
--cc=mark.rutland@arm.com \
--cc=rafael.j.wysocki@intel.com \
--cc=robert.moore@intel.com \
--cc=robh+dt@kernel.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®