Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:6 as permitted sender) client-ip=2620:137:e000::3:6;
Message-ID: <44e32b0e-0e41-4055-bdb9-15bc7d47197c@intel.com>
Date:   Wed, 25 Oct 2023 09:39:19 +0800
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] arm64: mm: drop tlb flush operation when clearing the
 access bit
Content-Language: en-US
To:     Barry Song <21cnbao@gmail.com>,
        Baolin Wang <baolin.wang@linux.alibaba.com>
CC:     <catalin.marinas@arm.com>, <will@kernel.org>,
        <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>
References: <ae3115778a3fa10ec77152e18beed54fafe0f6e7.1698151516.git.baolin.wang@linux.alibaba.com>
 <CAGsJ_4zgdAmyU-075jd8KfXn=CdAVC8Rs481sCOd5N2a68yPUg@mail.gmail.com>
From:   "Yin, Fengwei" <fengwei.yin@intel.com>
In-Reply-To: <CAGsJ_4zgdAmyU-075jd8KfXn=CdAVC8Rs481sCOd5N2a68yPUg@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?ZTZ0clF4eldxVThrYWIwWmVrQ3Q2QlNYK0lac2haVlg3M01scERhejZ3VGhM?=
 =?utf-8?B?OTd3KzFmNXcxY20xY0w0VUpqdUo4Q3k4Qy9jVUdpejV6WlpleWpsUHJUem1G?=
 =?utf-8?B?V3hJWU52UEFlbk9qQ3lVRXFETkthY1MvWkRGZC9sKzlFSFk0OFAvYXFkWjAz?=
 =?utf-8?B?eUpOYjhWMUtnRitVZUpid2lEQW0vMHdvcEdKN0lhTHcyaFRubDZ3RU5VZ2RQ?=
 =?utf-8?B?QkdVZHZyYjl1bkZvcmtaQlVwQWJyMXRmUkZ5NVJ6MDZpSFppQ0M4a1FGUm9H?=
 =?utf-8?B?VUphMHF4SHJGTWJxOWlJaytHLzZoR2FwM2pWczBGeHZ1K1hvUndPaUgxd2Zv?=
 =?utf-8?B?WDNMQXMvMG1qQ1dmME80a2tGTTlBREgvTDF0bFJoZkZXczFod3hLdEhsYU5s?=
 =?utf-8?B?Q2ViUmNqM1I0QWdLN3RkaDd0T2JmTWMzMmhmamZSTmo1em5ZRE9Zd245Rk90?=
 =?utf-8?B?MlcyNmR4ci9teGJUZ3dzdTlNVzExcVEzYkkyS1k5NGZGMVg1SGpNMHR1WGlk?=
 =?utf-8?B?SktVWWlnZGI2MHFmNFRjQ1FnU20rTGRaNWZDak5XSk9zc1BqRUNZQjN6VDZz?=
 =?utf-8?B?Y20ra1FwM1ZQVWZ1T1ZqSGJjdVJpRGZQSVYvWnBYb29jWmZtWllUUG90dGdL?=
 =?utf-8?B?QWJCaVdXZDBqOUR5ZHUrTzYwa25PMDBxNmdyZnRSdElVZFBJcnRMUy85bjNr?=
 =?utf-8?B?T2t0QVl0M0QwMG1COUV2eEoraXZScnJLMEhVK0ZFdFBoVDF6MkcxbUgwTmtn?=
 =?utf-8?B?NjhZRS9YaHdzY2ZhWmU0SXV0S3dtZDRQdHFBRGZXNHlRclc1U2ovYVVBWFY1?=
 =?utf-8?B?NmpoZWRkanRIc0c4RUNmZXpPTGVzcVdJVzNIc0YvVEtiZGFMd29IMXd2VXR6?=
 =?utf-8?B?enRkVkliOFJHTUJsNGpkY0RMSXNsa0Jway9oM0Z4Q3d1d1lqMWcxcnFoZmtu?=
 =?utf-8?B?SnlnaWdlQnl4dkhvVTFTcHdJcHNFQzNvQUdsOXpDRWszaGhsOUUxQlowMnVK?=
 =?utf-8?B?amxrR2lKT1RyNjJSTldnczNkVUVnRkRZTVh6VlpvSVk2RWVvZk9GUVAxMWpm?=
 =?utf-8?B?SVh1R3orSnNWY0ZFbWlRRWJMcVY4VnlXUlZwSWc0d05hSG5sWGF3STI2SlV0?=
 =?utf-8?B?R1lTZ0hjNVZPUnVJTlJ0OThpa2dtK0RTallMa1ZnYTZUaUxGMjc1Q2tsS29w?=
 =?utf-8?B?REJWUjhCL2VBR2JqMi9iYmtXOHNwbXN6S2dVZGVoZVozOWNjTWdJUWFvZkZB?=
 =?utf-8?B?enBlTjkraXdUY2Y4UldrYXpwd1RlaWwzYzE3VlJ0b1g5THVTMjJLVzJBY09w?=
 =?utf-8?B?QldaMExzVnJvYmhBZXVPaDQ1MGZFM0syQk1iOXJVQndPc1JEV2E4TXphTUo4?=
 =?utf-8?B?WEpKWm1rQnh2VGxiSEN3TGRCSy9rZzAyd05YNjI2YkpIQ3p5NXhYOG4yVXFF?=
 =?utf-8?B?OHY1U044dzlTWEpJT2xycEZyRXNNWjg2MERLME5PbVp3K2hROTJSM2dvbFNC?=
 =?utf-8?B?aGtiMEN2ZHlYRzhvUXBlc2xlVlR0RjJFN1Q3S2F0MEpEYU5YTmdHK0Rxa2xT?=
 =?utf-8?B?RVM0M1FVdFpjclRxMzdPU0VHeXNqanMxVXlJejVSYm4xSGlRaHRVZFYwMTZW?=
 =?utf-8?B?dWpxdklnT2YzbkxQdld6MWhIcXNsQjNtTTNSeUdabWtycys2Z1RSRTg5a0dk?=
 =?utf-8?B?L3FpalFtV2kvL0U0S1FzUUxXWDhPSVFIVGRHRTMxZ3dibG5wNmpLYittVXU0?=
 =?utf-8?B?N1dKaFhRWEQyeU50WWhBYmZuNUxXQ0ZDRW9HMXNhbnl0dUtIU29nelVTMTNP?=
 =?utf-8?B?MWhmY3JBVzgyOVE2ekpxLzBlZzdtbnFBQ3ltUm1Sb1B2TUZWTGVYWUJpQTZE?=
 =?utf-8?B?b3N2QnpaYlAwT0g3aUlyc01TeGZkQXhtSXl4dUJiKzFzWFZGa00rUEhGSy9t?=
 =?utf-8?B?WHBTMktoR1N6QlYyVTBsWS9hb3RrWTVZUlA2aWtIQUVqWC9FN1YrcEJ0TzdD?=
 =?utf-8?B?Q1gycFF3NnY5bEJhakcwckRaT2NjRVYveFpxaU9PYVBmNmZub0dFNXl1T3E4?=
 =?utf-8?B?dG0wR1M4NkZrMmFrMjJXQ1lCTnVNWVpmRVZTWGlTQy9tVzU2cmdZaTMweWln?=
 =?utf-8?Q?54UPC+BOZdEuHHEJUVZN9T3fu?=
X-MS-Exchange-CrossTenant-Network-Message-Id: 31ef2fa1-9480-4104-8ce7-08dbd4fb38ce
X-MS-Exchange-CrossTenant-AuthSource: CO1PR11MB4820.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Oct 2023 01:39:26.0528
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: vXk9H83GUkopXlEfW+E6zRoDQKyx4tF25R78gsEepK25rTh1SebrBNa/hibetI0mm+xYHDw57DCLSpf6qTcYGQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA1PR11MB7014
X-OriginatorOrg: intel.com
X-Spam-Status: No, score=-0.9 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,
	MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=unavailable
	autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on pete.vger.email
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (pete.vger.email [0.0.0.0]); Tue, 24 Oct 2023 18:39:44 -0700 (PDT)


>> diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
>> index 0bd18de9fd97..2979d796ba9d 100644
>> --- a/arch/arm64/include/asm/pgtable.h
>> +++ b/arch/arm64/include/asm/pgtable.h
>> @@ -905,21 +905,22 @@ static inline int ptep_test_and_clear_young(struct vm_area_struct *vma,
>>  static inline int ptep_clear_flush_young(struct vm_area_struct *vma,
>>                                          unsigned long address, pte_t *ptep)
>>  {
>> -       int young = ptep_test_and_clear_young(vma, address, ptep);
>> -
>> -       if (young) {
>> -               /*
>> -                * We can elide the trailing DSB here since the worst that can
>> -                * happen is that a CPU continues to use the young entry in its
>> -                * TLB and we mistakenly reclaim the associated page. The
>> -                * window for such an event is bounded by the next
>> -                * context-switch, which provides a DSB to complete the TLB
>> -                * invalidation.
>> -                */
>> -               flush_tlb_page_nosync(vma, address);
>> -       }
>> -
>> -       return young;
>> +       /*
>> +        * This comment is borrowed from x86, but applies equally to ARM64:
>> +        *
>> +        * 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. ]
>> +        */
>> +       return ptep_test_and_clear_young(vma, address, ptep);
>>  }
From https://lore.kernel.org/lkml/20181029105515.GD14127@arm.com/:

This is blindly copied from x86 and isn't true for us: we don't invalidate
the TLB on context switch. That means our window for keeping the stale
entries around is potentially much bigger and might not be a great idea.


My understanding is that arm64 doesn't do invalidate the TLB during
context switch. The flush_tlb_page_nosync() here + DSB during context
switch make sure the TLB is invalidated during context switch.
So we can't remove flush_tlb_page_nosync() here? Or something was changed
for arm64 (I have zero knowledge to TLB on arm64. So some obvious thing
may be missed)? Thanks.


Regards
Yin, Fengwei