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 67B87C0032E for ; Wed, 25 Oct 2023 03:25:37 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id EE34D6B0312; Tue, 24 Oct 2023 23:25:36 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E6B976B0313; Tue, 24 Oct 2023 23:25:36 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D334A6B0314; Tue, 24 Oct 2023 23:25:36 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id C07806B0312 for ; Tue, 24 Oct 2023 23:25:36 -0400 (EDT) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 811E64045E for ; Wed, 25 Oct 2023 03:25:36 +0000 (UTC) X-FDA: 81382543872.01.4638BCD Received: from out199-17.us.a.mail.aliyun.com (out199-17.us.a.mail.aliyun.com [47.90.199.17]) by imf04.hostedemail.com (Postfix) with ESMTP id EDE4B40013 for ; Wed, 25 Oct 2023 03:25:32 +0000 (UTC) Authentication-Results: imf04.hostedemail.com; dkim=none; spf=pass (imf04.hostedemail.com: domain of baolin.wang@linux.alibaba.com designates 47.90.199.17 as permitted sender) smtp.mailfrom=baolin.wang@linux.alibaba.com; dmarc=pass (policy=none) header.from=alibaba.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1698204334; 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; bh=4UufNtjdzUiUiXnIQCgtXf2XA5QPFJ+jWP3iSJaP1Jk=; b=EoUy66Hy2zfdXZMptqDm6k3PurnbrNu7OJrQT/nkeBoMQL3LBYmQWRdcY6MGF0pw/L2NR6 UqeHY1unNp5PXsQRX6nOf+i5hZkXV7+Mv1JvkXtKLV56dOZyhxKQ1csj0Dt8iM06FrbX9v g2bjMcPCvTHNv5264BLSDgyRrO7uCIw= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1698204334; a=rsa-sha256; cv=none; b=lZ7tTehDhrNuzO0c8g7oIdv9fvNd++RR6onQw1j7Kw857x2pFr4p5zv71WdK9GDvwyWjhV XgE65VoRXZowYKzY8tmLicY+uj/qCWNDp/DGzucjPza7YHjhqKvR2VrxK8FOsz93T51j6r rCuS23DA3hwtD9jd6cTaQqV+mNYcg3I= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=none; spf=pass (imf04.hostedemail.com: domain of baolin.wang@linux.alibaba.com designates 47.90.199.17 as permitted sender) smtp.mailfrom=baolin.wang@linux.alibaba.com; dmarc=pass (policy=none) header.from=alibaba.com X-Alimail-AntiSpam:AC=PASS;BC=-1|-1;BR=01201311R181e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=ay29a033018046049;MF=baolin.wang@linux.alibaba.com;NM=1;PH=DS;RN=10;SR=0;TI=SMTPD_---0Vusqgjq_1698203726; Received: from 30.97.48.63(mailfrom:baolin.wang@linux.alibaba.com fp:SMTPD_---0Vusqgjq_1698203726) by smtp.aliyun-inc.com; Wed, 25 Oct 2023 11:15:26 +0800 Message-ID: <0affd3de-cf20-72a1-a800-a0cbda539667@linux.alibaba.com> Date: Wed, 25 Oct 2023 11:15:42 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.15.1 Subject: Re: [PATCH] arm64: mm: drop tlb flush operation when clearing the access bit To: "Yin, Fengwei" , Barry Song <21cnbao@gmail.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: <44e32b0e-0e41-4055-bdb9-15bc7d47197c@intel.com> From: Baolin Wang In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: EDE4B40013 X-Rspam-User: X-Rspamd-Server: rspam11 X-Stat-Signature: 56wpgbpo1ffx847yubofpiiu4wegoixy X-HE-Tag: 1698204332-459643 X-HE-Meta: U2FsdGVkX1+Qq5uqWIGWXWo5zZ5xEMIicryVnSgmTeV1/Hwt5WniOHc+7ledH8W1Pc9+VSZaH7++CZKemWpt+VzYtMwK/Fb7sYQKb9swaV6sOrXEj4Rzasxjh/y3Z8zr3FkTFYViA/txtFQppFSca4y03+zesOmsA75YFeaMQBAvoikv12uW0gt/NxeNdZWeEKMLBM3wEpSmBNKKoTDSZ81UeCgcxba80I1ieFMXM2T248b7EA/kM07vq4z+rzQLZuUxjzk2ImvdIlt74LpHYdAABGh0r3mI7KAXCLY2bNQ4lW+IEUp1AAYEukTZpmdaBSqG049A10GzrmXPvk9UqNSL0GGMNqHC93qAT/oMqorPzOz9oEcEfP39XQq2qE9Aj+7FMd3IzlZyHWceiL0ODQr2kQxw3bpD37omstBXAfBEBwMM2b2n5/vjAXQNSb2CQVtLu4ocgtMvsKHG4oQA6ChhPFju1iTARAH2AmrIJBkv+i4MJq/UV75aZltEontDE9UrLzRu/1hzZgpM8nZcPb3Tm18K965LBfH0s31hTdc5pYaZjD3iSUHXAhXzChPdJopkBan8ZStyfy8yI/+fkbWxutOJodj93lg6s2bWkwFeSpPSIFP8ogFacIZPcdRVRr14tOPv+CwKko4LUG9/gEmRTQmF+LDCNpxs5V5auB438HycAvp2pUZ5TcfNS7fzkIx3+twH/HafU/Xg2OEzla4jVyKanEaygfkdnPuYO7OHhHaLunwhhqcjwgOLAD6L/azV0EBFIk6LP435x7fiY+4cwqCelPrZAJNFYMqd8AYVsyFx5C5jaZT8t2ZoAXD3knoyQ2k08Z/HjXlLo5CExEBxemy0uhaON/LHwYO/6tgLnKiKM6is9FlOR7jabjkdZZi00OoQih38laLJlCQHMXe4rwiqVQt2LWooNnbe5qQjI1834D5VTt7smIISNcMTZMJg7uFdIBfcTriD41w q1I2qVdv bU2R7HC5sUkD2w1wQFb3apG2b/ihG1JJJqvkfkP5XctkrI3x4uM5JiQqJkA+5aUCh3mRnQ2R3cXoiuWXwWpUMYiaiG5UOxpRPCtM3RBSH9pZkvWLtSt+laYTJhPWMOqboLMGAceEteY7LjTXTbylDHWRGdNptxg85aee5UEb3e6McPVk= 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 10/25/2023 11:08 AM, 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 context switch, and I think this is same with x86 IIUC. > If we remove flush_tlb_page_nosync(), can we still claim TLB is flushed during > context switch for ARM64? To be more precise, it is necessary to add prerequisite conditions, such as when ASID is exhausted. I can update the comments. >>> 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. >> >> IMHO, the tlb can be easily evicted or flushed if the system is under memory pressure, so like Barry said, the chance of reclaiming hot page is relatively 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_flush_young_notify(), and we did not find any problems until now since deploying to ARM servers.