All of lore.kernel.org
 help / color / mirror / Atom feed
From: "majun (Euler7)" <majun258@huawei.com>
To: Marc Zyngier <marc.zyngier@arm.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: majun258@huawei.com, 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 11:11:28 +0800	[thread overview]
Message-ID: <5844DAE0.9050101@huawei.com> (raw)
In-Reply-To: <bd4114c2-a6d9-123c-8f9f-e6da33a481ba@arm.com>

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


WARNING: multiple messages have this Message-ID (diff)
From: "majun (Euler7)" <majun258@huawei.com>
To: Marc Zyngier <marc.zyngier@arm.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: <majun258@huawei.com>, <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 11:11:28 +0800	[thread overview]
Message-ID: <5844DAE0.9050101@huawei.com> (raw)
In-Reply-To: <bd4114c2-a6d9-123c-8f9f-e6da33a481ba@arm.com>

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

  reply	other threads:[~2016-12-05  3:11 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-12-01  7:45 [RFC PATCH 0/3] Add a new flag for ITS device to control indirect route Majun
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   ` 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:45   ` 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  7:46   ` 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:29     ` majun (Euler7)
2016-12-02  9:35     ` Marc Zyngier
2016-12-05  3:11       ` majun (Euler7) [this message]
2016-12-05  3:11         ` majun (Euler7)
2016-12-05  9:00         ` Marc Zyngier

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=5844DAE0.9050101@huawei.com \
    --to=majun258@huawei.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=marc.zyngier@arm.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.