From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id EDECAC25B70 for ; Wed, 25 Oct 2023 04:34:34 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1D3926B0312; Wed, 25 Oct 2023 00:34:34 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 181866B0313; Wed, 25 Oct 2023 00:34:34 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 048D16B0314; Wed, 25 Oct 2023 00:34:33 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id E8D326B0312 for ; Wed, 25 Oct 2023 00:34:33 -0400 (EDT) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id BA7C3160C77 for ; Wed, 25 Oct 2023 04:34:33 +0000 (UTC) X-FDA: 81382717626.02.2BBB837 Received: from mail-vk1-f179.google.com (mail-vk1-f179.google.com [209.85.221.179]) by imf02.hostedemail.com (Postfix) with ESMTP id 0788A80008 for ; Wed, 25 Oct 2023 04:34:30 +0000 (UTC) Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=QFaIZHE+; spf=pass (imf02.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.221.179 as permitted sender) smtp.mailfrom=21cnbao@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1698208471; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=gVkIC9fUmLZDVWvlN2mUA1mgD/rtwCOE8cYC+FdYHCM=; b=PuA+hC8d+lH42QOwfbLpZGkGCfCorDAk07a1IN2IlPc8mwhhrNh7T8QP3ZYVGo/v15ABtr ehlaMGwnlJfGHnAhf7y2LxmfYzAnx/JJV5EteTKDxqHCw8jYHcDvBlIYWZU5CXJHGoZp1k nFkf3Kbaw71lDM5zQl1FTSjOpckKsZE= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=QFaIZHE+; spf=pass (imf02.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.221.179 as permitted sender) smtp.mailfrom=21cnbao@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1698208471; a=rsa-sha256; cv=none; b=JoZgIv1n8JAUNVg6oNEwQc7dFWCGRHR3WVHjXz/7LP1BPScIykUGH64Wp5dZgc71OmG6nw UgIg2tZD50eb0C1JctZitvzXFWr/XepBED9M6wrI9FVmKqjuOBKWc8sBYWOg1yrjn6GRNW 9FjANr+c1SY4JYUF+hggsuxVZTXUBRU= Received: by mail-vk1-f179.google.com with SMTP id 71dfb90a1353d-49d55b90a5aso322635e0c.0 for ; Tue, 24 Oct 2023 21:34:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1698208470; x=1698813270; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=gVkIC9fUmLZDVWvlN2mUA1mgD/rtwCOE8cYC+FdYHCM=; b=QFaIZHE+3B7aPZ2VJJVSy7KBKvN9BeZWPwoQWOGQkW08tH8q7KODivsramXtNtgnij S4exWB52GtG0d/J9KTrOFDqInE+nhz6rzmGVF2PxYepeJ6tZ/YBn2DiZ4E9+4fmBXbYI hXvRg/J8P1is3Lc22UgeRIsa76eDHhhUNmZbJ99kp34CwoQZivYxM9ba1b8xT6BMtEhp /8hmlQhyYGTM0ik3Bj3tqKScGcFr1Jv4RnJku1zmAm2eI1SbWEUbI0/1eTevr0pGOrym u2/0WGXayV0ybFwIUuxxI4JLc/DF8fez6sbZ+vqjLH9DpGbEyqtwH/651+VDnJ367KMf 5duQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1698208470; x=1698813270; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=gVkIC9fUmLZDVWvlN2mUA1mgD/rtwCOE8cYC+FdYHCM=; b=gab9RbvEgDPZZwFDYhBU7W74K8s0LQks7CWABpNARAkX1gX0Kk1Kyjria8FFb2Fkd0 f6NZoYkgGymxuaSKNoxiLoCIlITKJUAE1aW87njx8V/bUevJw+FmbApiOvbPbzIlTSjN gzSaKfOtPpKOZ3ZnXUxvSD5zlwqZ8eHx136ffVrYf2d4h5Y4XKUO3V+M2A5E33KsNJdM zgC1nTOzIAm75Em3A60BCUcnu4mJgR4Au2ieDtHvP4Fc2ZXWOQrpTBfef1MAJd5wtk2f 8GypgkEnV9Ji1E3+w10gCYdgy6FNXG2ClqJumvtJM8ZuslR3wRgP5m0MdM/gbWbAno8F eJTA== X-Gm-Message-State: AOJu0YwDgox/kshhaeF5511TANUP05lRVoZdyC77Dkq7rgxuZtrJ+avc VTSlaPETNNzx4kf/EC9OsZN/Vh8FWTlYDfH+BEQ= X-Google-Smtp-Source: AGHT+IGiUkhtzGa/ALcklBUpWuoI87pHjz1Amg9Y6T9HuMGZ6JAacd/9bYmnL0qPHH8WVBV5CGsFZYlM2/DL0pUM9yQ= X-Received: by 2002:a1f:7309:0:b0:494:63f7:4e7f with SMTP id o9-20020a1f7309000000b0049463f74e7fmr6799213vkc.2.1698208470086; Tue, 24 Oct 2023 21:34:30 -0700 (PDT) MIME-Version: 1.0 References: <44e32b0e-0e41-4055-bdb9-15bc7d47197c@intel.com> In-Reply-To: From: Barry Song <21cnbao@gmail.com> Date: Wed, 25 Oct 2023 12:34:17 +0800 Message-ID: Subject: Re: [PATCH] arm64: mm: drop tlb flush operation when clearing the access bit To: "Yin, Fengwei" Cc: Baolin Wang , 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 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 0788A80008 X-Rspam-User: X-Stat-Signature: xbrnjaoyubw8ytgzmym1wf3urxhmuewe X-Rspamd-Server: rspam01 X-HE-Tag: 1698208470-603174 X-HE-Meta: U2FsdGVkX19KCymA/SpfXlTLOAqUhq1KZUPnvDv7GHD0Npzv6QIYpWNP6odAJkiVOp5ILq7me2ohsLXkyq3CSUSojM9ai5IYktFyFeV+EKqyoP2gVeuLdzRQ/menJDg6GC5PPX5iZS++VQU14DpClGRA0ULtyRPtPqusRrdvFtRQuv1lKvBTYgSLdsXxqMQIFtNwKh68g/pw9wtoj9M0+iT0IzXbaLWpYGvVqj1Fi6TbiTQ/E9FLNoplVxkdcJeOGf8OC+v52fWehscBt2xWz6m0RtVqDwf4uplY1FOmQIGxcafan9nJX9yl3dr7ggSXv4ar7ewTIFIPEHvTf72InDxDONQmKAwJVUcVrWm0Kk1V69P75Q/e7tC5/Y75dJzGbn47W1/mQVZoAb+O7P8qW+cQ5/VpjCiRTQyABuyOhV2j+z/wzIfW4M4uJ6EhSMRBk7hT/9VPJnTcV6vY+lAP5B5i1P1xBYJtktO1xP/Dm3/1tM7Ph7fhpiVnB1iSdnTaBP49Rwux+u1v5JwVHbn3XLnxcOBWataMF8qCryRiwfs5TDCcA4dZywFzLelTUS0bHBNW/W/6Wxm+BCIgK9TsAMvgv6agggVhlFMeia4FVz4tXGsoE2KvD7yfRNPYPxcSXov0aiZAPR8vTr5ibs7EM94sSsoi1IYi9JqBIQFlPK/a3l6jnagQkc7fSMCJIwP+wqu2s0TSJh+ECM+rUaezmli8xrSrZEPqzXkGrWC9qZpXz3rrZQDNyk1szKSPl2C2uVdoFyjj/g36uggCX7JmfseydbG5Zf7AjnvK21IA95vg7QSxegDGlqTjtfWhUxeMTdiYHQsqHHrwNoJItaiAEI0NCnIu4U9UU0f6D+VngSCWrGGOrGnlhxD8Y/9v0oNQbR85MQmvp86xgPSRHlAx9syF7TBug/XpHfsg0L33OzENqRBvRb7W8OL4i/SCmBTKXFkErGdCYbpkDj6owIh +GtItanN 1Ml030bpZN7+SU8bPa5fQTbEwQnNKIj4V3k3Eg1JzgWMNFc0AvqqGvVWTSOmH0qQTfUwNtSoWALyNww89YuWcoOp4euIh0mwhvOAbBnphSYL1xFE33xIGK3U/4V6k0MhLea0qEiHRT67CGFOQMiWcdcRUhPuzH6Uv5n/6v8ySN9y322ZjPrG4TWt04Ih8jAtaXXcIvxPKMvWcEBHX/7mHGQdIOgTkzKmflMUjTtbvjczaObqG8W0hAe+ZhcQnwrsofZRplykqYoIZVJ0IQJVXiIcZq1fggm5mZXSzyLGPVJT/OIojzlbcdt1rrig9s2jnwhMciI3tQTrEHyiPtonnynVz6BpQQUif7+7b/bVcBwfN50caaE34ULxsOw== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Wed, Oct 25, 2023 at 11:09=E2=80=AFAM Yin, Fengwei wrote: > > > > On 10/25/2023 11:03 AM, Baolin Wang wrote: > >> > >> My understanding is that arm64 doesn't do invalidate the TLB during > = context switch. The flush_tlb_page_nosync() here + DSB during context > > > > Yes, we only perform a TLB flush when the ASID is exhausted during cont= ext switch, and I think this is same with x86 IIUC. > If we remove flush_tlb_page_nosync(), can we still claim TLB is flushed d= uring > context switch for ARM64? No. in this case, we will have to depend on hardware replacement of TLB on other CPUs. Considering LRU's list is really long and TLB is really small, a hot page needs a long time to move-back to inactive tail, other CPUs' TLB is likely to be replaced somewhere. But we do have a very small chance other CPUs will lose setting access flags in some corner cases. now i have more understanding why this nosync tlb flush is still there though in practical, removing it seems not to hurt. > > > > >> switch make sure the TLB is invalidated during context switch. > >> So we can't remove flush_tlb_page_nosync() here? Or something was chan= ged > >> for arm64 (I have zero knowledge to TLB on arm64. So some obvious thin= g > >> may be missed)? Thanks. > > > > IMHO, the tlb can be easily evicted or flushed if the system is under m= emory pressure, so like Barry said, the chance of reclaiming hot page is re= latively low, at least on X86, we did not see any heavy refault issue. > > > > For MGLRU, it uses ptep_test_and_clear_young() instead of ptep_clear_fl= ush_young_notify(), and we did not find any problems until now since deploy= ing to ARM servers. Thanks Barry