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

Groups > linux.kernel > #1533875 > unrolled thread

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

Back to article view | Back to linux.kernel

Contents

  [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

#1533875 — [RFC PATCH 0/3] Add a new flag for ITS device to control indirect route

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.

Although this function can save the memory needed, we'd better let the user
to decide enable or disable this function.

MaJun (3):
  Binding: Add a new property string in ITS node to control the two-level route function
  irqchip/gicv3-its:irqchip/gicv3-its: add a new flag to control indirect route in DT mode
  irqchip/gicv3-its:irqchip/gicv3-its: Add a new flag to control indirect route function in ACPI mode.

 .../bindings/interrupt-controller/arm,gic-v3.txt      |  3 +++
 drivers/irqchip/irq-gic-v3-its.c                      | 19 ++++++++++++++-----
 include/acpi/actbl1.h                                 |  3 ++-
 3 files changed, 19 insertions(+), 6 deletions(-)

-- 
1.7.12.4

[toc] | [next] | [standalone]

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

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?

Anyway, doing this as a DT quirk doesn't feel right. Please use the ITS
quirk infrastructure.

Thanks,

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

[toc] | [prev] | [next] | [standalone]

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

在 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.
> 
> Anyway, doing this as a DT quirk doesn't feel right. Please use the ITS
> quirk infrastructure.

If there is no other better solutions, I will do this.

Thanks!
Majun



> 
> Thanks,
> 
> 	M.
> 

[toc] | [prev] | [next] | [standalone]

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

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?

>> Anyway, doing this as a DT quirk doesn't feel right. Please use the ITS
>> quirk infrastructure.
> 
> If there is no other better solutions, I will do this.

Thanks,

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

[toc] | [prev] | [next] | [standalone]

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

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.

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.

Thanks
Majun

>>> Anyway, doing this as a DT quirk doesn't feel right. Please use the ITS
>>> quirk infrastructure.
>>
>> If there is no other better solutions, I will do this.
> 
> Thanks,
> 
> 	M.
> 

[toc] | [prev] | [next] | [standalone]

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

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

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web