Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.37 as permitted sender) client-ip=23.128.96.37;
MIME-Version: 1.0
References: <ae3115778a3fa10ec77152e18beed54fafe0f6e7.1698151516.git.baolin.wang@linux.alibaba.com>
 <CAGsJ_4zgdAmyU-075jd8KfXn=CdAVC8Rs481sCOd5N2a68yPUg@mail.gmail.com>
 <44e32b0e-0e41-4055-bdb9-15bc7d47197c@intel.com> <f3047412-a53c-f8ba-f8aa-4f46e04c5a31@linux.alibaba.com>
 <a4ae7473-636b-4ff3-9f66-f47dbe934593@intel.com>
In-Reply-To: <a4ae7473-636b-4ff3-9f66-f47dbe934593@intel.com>
From:   Barry Song <21cnbao@gmail.com>
Date:   Wed, 25 Oct 2023 12:34:17 +0800
Message-ID: <CAGsJ_4x+UBtJNaGw8CswRrcDtNwXAGRUN8NogKMd5=MJRpyisw@mail.gmail.com>
Subject: Re: [PATCH] arm64: mm: drop tlb flush operation when clearing the
 access bit
To:     "Yin, Fengwei" <fengwei.yin@intel.com>
Cc:     Baolin Wang <baolin.wang@linux.alibaba.com>,
        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
Precedence: bulk

On Wed, Oct 25, 2023 at 11:09=E2=80=AFAM Yin, Fengwei <fengwei.yin@intel.co=
m> 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