Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1535925

Re: [RFC PATCH 0/3] Add a new flag for ITS device to control indirect route

From Marc Zyngier <marc.zyngier@arm.com>
Newsgroups linux.kernel
Subject Re: [RFC PATCH 0/3] Add a new flag for ITS device to control indirect route
Date 2016-12-05 10:20 +0100
Message-ID <sKXBh-2G5-55@gated-at.bofh.it> (permalink)
References <sJuhX-PI-7@gated-at.bofh.it> <sJvxn-1QI-15@gated-at.bofh.it> <sJStY-22N-11@gated-at.bofh.it> <sJStY-22N-25@gated-at.bofh.it> <sKRYS-7qO-17@gated-at.bofh.it>
Organization ARM Ltd

Show all headers | View raw


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...

Back to linux.kernel | Previous | NextPrevious in thread | Find similar | Unroll thread


Thread

[RFC PATCH 0/3] Add a new flag for ITS device to control indirect route Majun <majun258@huawei.com> - 2016-12-01 08:50 +0100
  Re: [RFC PATCH 0/3] Add a new flag for ITS device to control indirect  route Marc Zyngier <marc.zyngier@arm.com> - 2016-12-01 10:10 +0100
    Re: [RFC PATCH 0/3] Add a new flag for ITS device to control indirect  route "majun (Euler7)" <majun258@huawei.com> - 2016-12-02 10:40 +0100
      Re: [RFC PATCH 0/3] Add a new flag for ITS device to control indirect  route Marc Zyngier <marc.zyngier@arm.com> - 2016-12-02 10:40 +0100
        Re: [RFC PATCH 0/3] Add a new flag for ITS device to control indirect  route "majun (Euler7)" <majun258@huawei.com> - 2016-12-05 04:20 +0100
          Re: [RFC PATCH 0/3] Add a new flag for ITS device to control indirect  route Marc Zyngier <marc.zyngier@arm.com> - 2016-12-05 10:20 +0100

csiph-web