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: Fri, 2 Dec 2016 17:29:50 +0800	[thread overview]
Message-ID: <58413F0E.3030604@huawei.com> (raw)
In-Reply-To: <3ce161a7-ee63-a018-4a75-9e7520143d97@arm.com>



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


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: Fri, 2 Dec 2016 17:29:50 +0800	[thread overview]
Message-ID: <58413F0E.3030604@huawei.com> (raw)
In-Reply-To: <3ce161a7-ee63-a018-4a75-9e7520143d97@arm.com>



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

  reply	other threads:[~2016-12-02  9:30 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) [this message]
2016-12-02  9:29     ` majun (Euler7)
2016-12-02  9:35     ` Marc Zyngier
2016-12-05  3:11       ` majun (Euler7)
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=58413F0E.3030604@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.