From: Baolin Wang <baolin.wang@linux.alibaba.com>
To: Kefeng Wang <wangkefeng.wang@huawei.com>,
catalin.marinas@arm.com, will@kernel.org
Cc: akpm@linux-foundation.org, v-songbaohua@oppo.com,
yuzhao@google.com, linux-mm@kvack.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] arm64: mm: drop tlb flush operation when clearing the access bit
Date: Wed, 25 Oct 2023 09:44:34 +0800 [thread overview]
Message-ID: <e818ef93-49f6-47c8-0d89-6330bf6687f8@linux.alibaba.com> (raw)
In-Reply-To: <e0b65883-18fa-40c8-a61a-bebcfee109a4@huawei.com>
On 10/24/2023 9:48 PM, Kefeng Wang wrote:
>
>
> On 2023/10/24 20:56, Baolin Wang wrote:
>> Now ptep_clear_flush_young() is only called by folio_referenced() to
>> check if the folio was referenced, and now it will call a tlb flush on
>> ARM64 architecture. However the tlb flush can be expensive on ARM64
>> servers, especially for the systems with a large CPU numbers.
>>
>> Similar to the x86 architecture, below comments also apply equally to
>> ARM64 architecture. So we can drop the tlb flush operation in
>> ptep_clear_flush_young() on ARM64 architecture to improve the
>> performance.
>> "
>> /* Clearing the accessed bit without a TLB flush
>> * doesn't cause data corruption. [ It could cause incorrect
>> * page aging and the (mistaken) reclaim of hot pages, but the
>> * chance of that should be relatively low. ]
>> *
>> * So as a performance optimization don't flush the TLB when
>> * clearing the accessed bit, it will eventually be flushed by
>> * a context switch or a VM operation anyway. [ In the rare
>> * event of it not getting flushed for a long time the delay
>> * shouldn't really matter because there's no real memory
>> * pressure for swapout to react to. ]
>> */
>> "
>> Running the thpscale to show some obvious improvements for compaction
>> latency with this patch:
>> base patched
>> Amean fault-both-1 1093.19 ( 0.00%) 1084.57 * 0.79%*
>> Amean fault-both-3 2566.22 ( 0.00%) 2228.45 * 13.16%*
>> Amean fault-both-5 3591.22 ( 0.00%) 3146.73 * 12.38%*
>> Amean fault-both-7 4157.26 ( 0.00%) 4113.67 * 1.05%*
>> Amean fault-both-12 6184.79 ( 0.00%) 5218.70 * 15.62%*
>> Amean fault-both-18 9103.70 ( 0.00%) 7739.71 * 14.98%*
>> Amean fault-both-24 12341.73 ( 0.00%) 10684.23 * 13.43%*
>> Amean fault-both-30 15519.00 ( 0.00%) 13695.14 * 11.75%*
>> Amean fault-both-32 16189.15 ( 0.00%) 14365.73 * 11.26%*
>> base patched
>> Duration User 167.78 161.03
>> Duration System 1836.66 1673.01
>> Duration Elapsed 2074.58 2059.75
>>
>> Barry Song submitted a similar patch [1] before, that replaces the
>> ptep_clear_flush_young_notify() with ptep_clear_young_notify() in
>> folio_referenced_one(). However, I'm not sure if removing the tlb flush
>> operation is applicable to every architecture in kernel, so dropping
>> the tlb flush for ARM64 seems a sensible change.
>
> At least x86/s390/riscv/powerpc already do it, also I think we could
Right.
> change pmdp_clear_flush_young_notify() too, since it is same with
> ptep_clear_flush_young_notify(),
Perhaps yes, but I'm still unsure if removing tlb flush for PMD entry is
applicable to all architectures. Let's see the discussion in this
thread. Thanks.
next prev parent reply other threads:[~2023-10-25 1:44 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-24 12:56 Baolin Wang
2023-10-24 13:48 ` Kefeng Wang
2023-10-25 1:44 ` Baolin Wang [this message]
2023-10-24 22:32 ` Yu Zhao
2023-10-24 23:16 ` Barry Song
2023-10-24 23:31 ` Barry Song
2023-10-25 1:07 ` Alistair Popple
2023-10-25 1:44 ` Barry Song
2023-10-25 1:58 ` Alistair Popple
2023-10-25 2:43 ` Baolin Wang
2023-10-25 3:09 ` Alistair Popple
2023-10-25 6:17 ` Yu Zhao
2023-10-25 6:27 ` Barry Song
2023-10-25 10:12 ` Alistair Popple
2023-10-25 18:22 ` Yu Zhao
2023-10-25 23:32 ` Alistair Popple
2023-10-26 23:48 ` Barry Song
2023-10-25 2:02 ` Baolin Wang
2023-10-25 1:39 ` Yin, Fengwei
2023-10-25 3:03 ` Baolin Wang
2023-10-25 3:08 ` Yin, Fengwei
2023-10-25 3:15 ` Baolin Wang
2023-10-25 4:34 ` Barry Song
2023-11-07 10:12 ` Will Deacon
2023-11-07 20:50 ` Barry Song
2023-10-26 4:55 ` Anshuman Khandual
2023-10-26 5:54 ` Barry Song
2023-10-26 6:01 ` Anshuman Khandual
2023-10-26 12:30 ` Robin Murphy
2023-10-26 12:32 ` Baolin Wang
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=e818ef93-49f6-47c8-0d89-6330bf6687f8@linux.alibaba.com \
--to=baolin.wang@linux.alibaba.com \
--cc=akpm@linux-foundation.org \
--cc=catalin.marinas@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=v-songbaohua@oppo.com \
--cc=wangkefeng.wang@huawei.com \
--cc=will@kernel.org \
--cc=yuzhao@google.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