From: Zhenyu Ye <yezhenyu2@huawei.com>
To: Will Deacon <will@kernel.org>
Cc: <catalin.marinas@arm.com>, <maz@kernel.org>,
<suzuki.poulose@arm.com>, <mark.rutland@arm.com>,
<tangnianyao@huawei.com>, <xiexiangyou@huawei.com>,
<linux-kernel@vger.kernel.org>, <arm@kernel.org>
Subject: Re: [RFC PATCH v2] arm64: cpufeatures: add support for tlbi range instructions
Date: Mon, 11 Nov 2019 21:47:12 +0800 [thread overview]
Message-ID: <5DC96660.8040505@huawei.com> (raw)
In-Reply-To: <20191111132716.GA9394@willie-the-truck>
On 2019/11/11 21:27, Will Deacon wrote:
> On Mon, Nov 11, 2019 at 09:23:55PM +0800, Zhenyu Ye wrote:
>> ARMv8.4-TLBI provides TLBI invalidation instruction that apply to a
>> range of input addresses. This patch adds support for this feature.
>> This is the second version of the patch.
>>
>> I traced the __flush_tlb_range() for a minute and get some statistical
>> data as below:
>>
>> PAGENUM COUNT
>> 1 34944
>> 2 5683
>> 3 1343
>> 4 7857
>> 5 838
>> 9 339
>> 16 933
>> 19 427
>> 20 5821
>> 23 279
>> 41 338
>> 141 279
>> 512 428
>> 1668 120
>> 2038 100
>>
>> Those data are based on kernel-5.4.0, where PAGENUM = end - start, COUNT
>> shows number of calls to the __flush_tlb_range() in a minute. There only
>> shows the data which COUNT >= 100. The kernel is started normally, and
>> transparent hugepage is opened. As we can see, though most user TLBI
>> ranges were 1 pages long, the num of long-range can not be ignored.
>>
>> The new feature of TLB range can improve lots of performance compared to
>> the current implementation. As an example, flush 512 ranges needs only 1
>> instruction as opposed to 512 instructions using current implementation.
>>
>> And for a new hardware feature, support is better than not.
>>
>> Signed-off-by: Zhenyu Ye <yezhenyu2@huawei.com>
>> ---
>> ChangeLog v1 -> v2:
>> - Change the main implementation of this feature.
>> - Add some comments.
>
> How does this address my concerns here:
>
> https://lore.kernel.org/linux-arm-kernel/20191031131649.GB27196@willie-the-truck/
>
> ?
>
> Will
>
> .
>
I think your concern is more about the hardware level, and we can do nothing about
this at all. The interconnect/DVM implementation is not exposed to software layer
(and no need), and may should be constrained at hardware level.
Zhenyu
next prev parent reply other threads:[~2019-11-11 13:47 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-11 13:23 [RFC PATCH v2] arm64: cpufeatures: add support for tlbi range instructions Zhenyu Ye
2019-11-11 13:27 ` Will Deacon
2019-11-11 13:47 ` Zhenyu Ye [this message]
2019-11-11 14:04 ` Marc Zyngier
2019-11-11 14:23 ` Zhenyu Ye
2019-11-19 1:13 ` Hanjun Guo
2019-11-19 10:03 ` Marc Zyngier
2019-11-20 1:29 ` Hanjun Guo
2019-11-20 8:47 ` Will Deacon
2019-11-11 16:32 ` Olof Johansson
2019-11-12 2:19 ` Zhenyu Ye
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=5DC96660.8040505@huawei.com \
--to=yezhenyu2@huawei.com \
--cc=arm@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=maz@kernel.org \
--cc=suzuki.poulose@arm.com \
--cc=tangnianyao@huawei.com \
--cc=will@kernel.org \
--cc=xiexiangyou@huawei.com \
/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;
as well as URLs for NNTP newsgroup(s).