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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id A37B8C25B48 for ; Wed, 25 Oct 2023 02:43:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:Content-Type: Content-Transfer-Encoding:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:From:References:Cc:To:Subject: MIME-Version:Date:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=tDxBRsBFK8PM0bjeR+MHlc96EjyHEgnYVEbInDEzMkU=; b=dD1LEx6V3YXIW2 PQCgaEjGdVKqVpleGcKmn4knNiXaZJq1OqmlNzSOdcxveptiWJDeoQ/h3YsU0a6+JzR3ClRqpXit4 7nVG+HVbZtL+TMz41DSnhLJrJaZgOq3BCicWub61OJhUV/LW5VmTtEH426/vKCb6fVjGPO5yXD97I uOjTaD6N6T95n1GuI1fGqBi7vw3yApGmJIm2JcbMiMDH+VFnfvADgNaC2DcEm4aWuLqpWhg07Vkmu uUCt44WGsDLn29bH9860vblmJ4FU/iEWXztDfnWXIWt4atii9UrVTz39zLks/rxOJmxX6DWw3Sm4Z ghkW/M13GfhbG5IU3VhA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1qvTrb-00BCgN-1I; Wed, 25 Oct 2023 02:43:19 +0000 Received: from out30-131.freemail.mail.aliyun.com ([115.124.30.131]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1qvTrU-00BCfX-2C for linux-arm-kernel@lists.infradead.org; Wed, 25 Oct 2023 02:43:17 +0000 X-Alimail-AntiSpam: AC=PASS;BC=-1|-1;BR=01201311R721e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=ay29a033018045176;MF=baolin.wang@linux.alibaba.com;NM=1;PH=DS;RN=10;SR=0;TI=SMTPD_---0Vusq8o5_1698201785; Received: from 30.97.48.63(mailfrom:baolin.wang@linux.alibaba.com fp:SMTPD_---0Vusq8o5_1698201785) by smtp.aliyun-inc.com; Wed, 25 Oct 2023 10:43:06 +0800 Message-ID: Date: Wed, 25 Oct 2023 10:43:21 +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: Alistair Popple , 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: <87y1frqz2u.fsf@nvdebian.thelocal> <87ttqfqw8f.fsf@nvdebian.thelocal> From: Baolin Wang In-Reply-To: <87ttqfqw8f.fsf@nvdebian.thelocal> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20231024_194313_152832_3C5E70A3 X-CRM114-Status: GOOD ( 42.81 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org CgpPbiAxMC8yNS8yMDIzIDk6NTggQU0sIEFsaXN0YWlyIFBvcHBsZSB3cm90ZToKPiAKPiBCYXJy eSBTb25nIDwyMWNuYmFvQGdtYWlsLmNvbT4gd3JpdGVzOgo+IAo+PiBPbiBXZWQsIE9jdCAyNSwg MjAyMyBhdCA5OjE44oCvQU0gQWxpc3RhaXIgUG9wcGxlIDxhcG9wcGxlQG52aWRpYS5jb20+IHdy b3RlOgo+Pj4KPj4+Cj4+PiBCYXJyeSBTb25nIDwyMWNuYmFvQGdtYWlsLmNvbT4gd3JpdGVzOgo+ Pj4KPj4+PiBPbiBXZWQsIE9jdCAyNSwgMjAyMyBhdCA3OjE24oCvQU0gQmFycnkgU29uZyA8MjFj bmJhb0BnbWFpbC5jb20+IHdyb3RlOgo+Pj4+Pgo+Pj4+PiBPbiBUdWUsIE9jdCAyNCwgMjAyMyBh dCA4OjU34oCvUE0gQmFvbGluIFdhbmcKPj4+Pj4gPGJhb2xpbi53YW5nQGxpbnV4LmFsaWJhYmEu Y29tPiB3cm90ZToKPiAKPiBbLi4uXQo+IAo+Pj4+PiAoQSkuIENvbnN0YW50IGZsdXNoIGNvc3Qg dnMuIChCKS4gdmVyeSB2ZXJ5IG9jY2FzaW9uYWwgcmVjbGFpbWVkIGhvdAo+Pj4+PiBwYWdlLCAg QiBtaWdodAo+Pj4+PiBiZSBhIGNvcnJlY3QgY2hvaWNlLgo+Pj4+Cj4+Pj4gUGx1cywgSSBkb3Vi dCBCIGlzIHJlYWxseSBnb2luZyB0byBoYXBwZW4uIGFzIGFmdGVyIGEgcGFnZSBpcyBwcm9tb3Rl ZCB0bwo+Pj4+IHRoZSBoZWFkIG9mIGxydSBsaXN0IG9yIG5ldyBnZW5lcmF0aW9uLCBpdCBuZWVk cyBhIGxvbmcgdGltZSB0byBzbGlkZSBiYWNrCj4+Pj4gdG8gdGhlIGluYWN0aXZlIGxpc3QgdGFp bCBvciB0byB0aGUgY2FuZGlkYXRlIGdlbmVyYXRpb24gb2YgbWdscnUuIHRoZSB0aW1lCj4+Pj4g c2hvdWxkIGhhdmUgYmVlbiBsYXJnZSBlbm91Z2ggZm9yIHRsYiB0byBiZSBmbHVzaGVkLiBJZiB0 aGUgcGFnZSBpcyByZWFsbHkKPj4+PiBob3QsIHRoZSBoYXJkd2FyZSB3aWxsIGdldCBzZWNvbmQs IHRoaXJkLCBmb3VydGggZXRjIG9wcG9ydHVuaXR5IHRvIHNldCBhbgo+Pj4+IGFjY2VzcyBmbGFn IGluIHRoZSBsb25nIHRpbWUgaW4gd2hpY2ggdGhlIHBhZ2UgaXMgcmUtbW92ZWQgdG8gdGhlIHRh aWwKPj4+PiBhcyB0aGUgcGFnZSBjYW4gYmUgYWNjZXNzZWQgbXVsdGlwbGUgdGltZXMgaWYgaXQg aXMgcmVhbGx5IGhvdC4KPj4+Cj4+PiBUaGlzIG1pZ2h0IG5vdCBiZSB0cnVlIGlmIHlvdSBoYXZl IGV4dGVybmFsIGhhcmR3YXJlIHNoYXJpbmcgdGhlIHBhZ2UKPj4+IHRhYmxlcyB3aXRoIHNvZnR3 YXJlIHRocm91Z2ggZWl0aGVyIEhNTSBvciBoYXJkd2FyZSBzdXBwb3J0ZWQgQVRTCj4+PiB0aG91 Z2guCj4+Pgo+Pj4gSW4gdGhvc2UgY2FzZXMgSSB0aGluayBpdCdzIG11Y2ggbW9yZSBsaWtlbHkg aGFyZHdhcmUgY2FuIHN0aWxsIGJlCj4+PiBhY2Nlc3NpbmcgdGhlIHBhZ2UgZXZlbiBhZnRlciBh IGNvbnRleHQgc3dpdGNoIG9uIHRoZSBDUFUgc2F5LiBTbyB0aG9zZQo+Pj4gcGFnZXMgd2lsbCB0 ZW5kIHRvIGdldCByZWNsYWltZWQgZXZlbiB0aG91Z2ggaGFyZHdhcmUgaXMgc3RpbGwgYWN0aXZl bHkKPj4+IHVzaW5nIHRoZW0gd2hpY2ggd291bGQgYmUgcXVpdGUgZXhwZW5zaXZlIGFuZCBJIGd1 ZXNzIGNvdWxkIGxlYWQgdG8KPj4+IHRocmFzaGluZyBhcyBlYWNoIHBhZ2UgaXMgcmVjbGFpbWVk IGFuZCB0aGVuIGltbWVkaWF0ZWx5IGZhdWx0ZWQgYmFjawo+Pj4gaW4uCgpUaGF0J3MgcG9zc2li bGUsIGJ1dCB0aGUgY2hhbmNlIHNob3VsZCBiZSByZWxhdGl2ZWx5IGxvdy4gQXQgbGVhc3Qgb24g Cng4NiwgSSBoYXZlIG5vdCBoZWFyZCBvZiB0aGlzIGlzc3VlLgoKPj4gaSBhbSBub3QgcXVpdGUg c3VyZSBpIGdvdCB5b3VyIHBvaW50LiBoYXMgdGhlIGV4dGVybmFsIGhhcmR3YXJlIHNoYXJpbmcg Y3B1J3MKPj4gcGFnZXRhYmxlIHRoZSBhYmlsaXR5IHRvIHNldCBhY2Nlc3MgZmxhZyBpbiBwYWdl IHRhYmxlIGVudHJpZXMgYnkKPj4gaXRzZWxmPyBpZiB5ZXMsCj4+IEkgZG9uJ3Qgc2VlIGhvdyBv dXIgYXBwcm9hY2ggd2lsbCBodXJ0IGFzIGZvbGlvX3JlZmVyZW5jZWQgY2FuIG5vdGlmeSB0aGUK Pj4gaGFyZHdhcmUgZHJpdmVyIGFuZCB0aGUgZHJpdmVyIGNhbiBmbHVzaCBpdHMgb3duIHRsYi4g SWYgbm8sIGkgZG9uJ3Qgc2VlCj4+IGVpdGhlciBhcyB0aGUgZXh0ZXJuYWwgaGFyZHdhcmUgY2Fu J3Qgc2V0IGFjY2VzcyBmbGFncywgdGhhdCBtZWFucyB3ZQo+PiBoYXZlIGlnbm9yZWQgaXRzIHJl ZmVyZW5jZSBhbmQgb25seSBrbm93cyBjcHUncyBhY2Nlc3MgZXZlbiBpbiB0aGUgY3VycmVudAo+ PiBtYWlubGluZSBjb2RlLiBzbyB3ZSBhcmUgbm90IGdldHRpbmcgd29yc2UuCj4+Cj4+IHNvIHRo ZSBleHRlcm5hbCBoYXJkd2FyZSBjYW4gYWxzbyBzZWUgY3B1J3MgVExCPyBvciBjcHUncyB0bGIg Zmx1c2ggY2FuCj4+IGFsc28gYnJvYWRjYXN0IHRvIGV4dGVybmFsIGhhcmR3YXJlLCB0aGVuIGV4 dGVybmFsIGhhcmR3YXJlIHNlZXMgdGhlCj4+IGNsZWFyZWQgYWNjZXNzIGZsYWcsIHRodXMsIGl0 IGNhbiBzZXQgYWNjZXNzIGZsYWcgaW4gcGFnZSB0YWJsZSB3aGVuIHRoZQo+PiBoYXJkd2FyZSBh Y2Nlc3MgaXQ/ICBJZiB0aGlzIGlzIHRoZSBjYXNlLCBJIGZlZWwgd2hhdCB5b3Ugc2FpZCBpcyB0 cnVlLgo+IAo+IFBlcmhhcHMgaXQgd291bGQgaGVscCBpZiBJIGdhdmUgYSBjb25jcmV0ZSBleGFt cGxlLiBUYWtlIGZvciBleGFtcGxlIHRoZQo+IEFSTSBTTU1VLiBJdCBoYXMgaXQncyBvd24gVExC LiBJbnZhbGlkYXRpbmcgdGhpcyBUTEIgaXMgZG9uZSBpbiBvbmUgb2YKPiB0d28gd2F5cyBkZXBl bmRpbmcgb24gdGhlIHNwZWNpZmljIEhXIGltcGxlbWVudGF0aW9uLgo+IAo+IElmIGJyb2FkY2Fz dCBUTEIgbWFpbnRlbmFuY2UgKEJUTSkgaXMgc3VwcG9ydGVkIGl0IHdpbGwgc25vb3AgQ1BVIFRM Qgo+IGludmFsaWRhdGlvbnMuIElmIEJUTSBpcyBub3Qgc3VwcG9ydGVkIGl0IHJlbGllcyBvbiBT VyB0byBleHBsaWNpdGx5Cj4gZm9yd2FyZCBUTEIgaW52YWxpZGF0aW9ucyB2aWEgTU1VIG5vdGlm aWVycy4KCk9uIG91ciBBUk02NCBoYXJkd2FyZSwgd2UgcmVseSBvbiBCVE0gdG8gbWFpbnRhaW4g VExCIGNvaGVyZW5jeS4KCj4gTm93IGNvbnNpZGVyIHRoZSBjYXNlIHdoZXJlIHNvbWUgZXh0ZXJu YWwgZGV2aWNlIGlzIGFjY2Vzc2luZyBtYXBwaW5ncwo+IHZpYSB0aGUgU01NVS4gVGhlIGFjY2Vz cyBmbGFnIHdpbGwgYmUgY2FjaGVkIGluIHRoZSBTTU1VIFRMQi4gSWYgd2UKPiBjbGVhciB0aGUg YWNjZXNzIGZsYWcgd2l0aG91dCBhIFRMQiBpbnZhbGlkYXRlIHRoZSBhY2Nlc3MgZmxhZyBpbiB0 aGUKPiBDUFUgcGFnZSB0YWJsZSB3aWxsIG5vdCBnZXQgdXBkYXRlZCBiZWNhdXNlIGl0J3MgYWxy ZWFkeSBzZXQgaW4gdGhlIFNNTVUKPiBUTEIuCj4gCj4gQXMgYW4gYXNpZGUgYWNjZXNzIGZsYWcg dXBkYXRlcyBoYXBwZW4gaW4gb25lIG9mIHR3byB3YXlzLiBJZiB0aGUgU01NVQo+IEhXIHN1cHBv cnRzIGhhcmR3YXJlIHRyYW5zbGF0aW9uIHRhYmxlIHVwZGF0ZXMgKEhUVFUpIHRoZW4gaGFyZHdh cmUgd2lsbAo+IG1hbmFnZSB1cGRhdGluZyBhY2Nlc3MvZGlydHkgZmxhZ3MgYXMgcmVxdWlyZWQu IElmIHRoaXMgaXMgbm90IHN1cHBvcnRlZAo+IHRoZW4gU1cgaXMgcmVsaWVkIG9uIHRvIHVwZGF0 ZSB0aGVzZSBmbGFncyB3aGljaCBpbiBwcmFjdGljZSBtZWFucwo+IHRha2luZyBhIG1pbm9yIGZh dWx0LiBCdXQgSSBkb24ndCB0aGluayB0aGF0IGlzIHJlbGV2YW50IGhlcmUgLSBpbgo+IGVpdGhl ciBjYXNlIHdpdGhvdXQgYSBUTEIgaW52YWxpZGF0ZSBuZWl0aGVyIG9mIHRob3NlIHRoaW5ncyB3 aWxsCj4gaGFwcGVuLgo+IAo+IEkgc3VwcG9zZSBkcml2ZXJzIGNvdWxkIGltcGxlbWVudCB0aGUg Y2xlYXJfZmx1c2hfeW91bmcoKSBNTVUgbm90aWZpZXIKPiBjYWxsYmFjayAobm9uZSBkbyBhdCB0 aGUgbW9tZW50IEFGQUlDVCkgYnV0IHRoZW4gd29uJ3QgdGhhdCBqdXN0IGxlYWQgdG8KPiB0aGUg b3Bwb3NpdGUgcHJvYmxlbSAtIHRoYXQgZXZlcnkgcGFnZSBldmVyIHVzZWQgYnkgYW4gZXh0ZXJu YWwgZGV2aWNlCj4gcmVtYWlucyBhY3RpdmUgYW5kIHVuYXZhaWxhYmxlIGZvciByZWNsYWltIGJl Y2F1c2UgdGhlIGFjY2VzcyBmbGFnIG5ldmVyCj4gZ2V0cyBjbGVhcmVkPyBJIHN1cHBvc2UgdGhl eSBjb3VsZCBkbyB0aGUgZmx1c2ggdGhlbiB3aGljaCB3b3VsZCBlbnN1cmUKClllcywgSSB0aGlu ayBzbyB0b28uIFRoZSByZWFzb24gdGhlcmUgaXMgY3VycmVudGx5IG5vIHByb2JsZW0sIHBlcmhh cHMgSSAKdGhpbmssIHRoZXJlIGFyZSBubyBhY3R1YWwgdXNlIGNhc2VzIGF0IHRoZSBtb21lbnQ/ IEF0IGxlYXN0IG9uIG91ciAKQWxpYmFiYSdzIGZsZWV0LCBTTU1VIGFuZCBNTVUgZG8gbm90IHNo YXJlIHBhZ2UgdGFibGVzIG5vdy4KCj4gdGhlIHBhZ2UgaXMgbWFya2VkIGluYWN0aXZlIGlmIGl0 J3Mgbm90IHJlZmVyZW5jZWQgYmV0d2VlbiB0aGUgdHdvCj4gZm9saW9fcmVmZXJlbmNlZCBjYWxs cygpLgo+IAo+IEJ1dCB0aGF0IHJlcXVpcmVzIGNoYW5nZXMgdG8gdGhvc2UgZHJpdmVycy4gU01N VSBmcm9tIG1lbW9yeSBkb2Vzbid0Cj4gZXZlbiByZWdpc3RlciBmb3Igbm90aWZpZXJzIGlmIEJU TSBpcyBzdXBwb3J0ZWQuCj4gCj4gICAtIEFsaXN0YWlyCj4gCj4+Pgo+Pj4gT2YgY291cnNlIFRM QiBmbHVzaGVzIGFyZSBlcXVhbGx5IChwZXJoYXBzIGV2ZW4gbW9yZSkgZXhwZW5zaXZlIGZvciB0 aGlzCj4+PiBraW5kIG9mIGV4dGVybmFsIEhXIHNvIHJlZHVjaW5nIHRoZW0gd291bGQgc3RpbGwg YmUgYmVuZWZpY2lhbC4gSSB3b25kZXIKPj4+IGlmIHRoZXJlJ3Mgc29tZSB3YXkgdGhleSBjb3Vs ZCBiZSBkZWZlcnJlZCB1bnRpbCB0aGUgcGFnZSBpcyBtb3ZlZCB0bwo+Pj4gdGhlIGluYWN0aXZl IGxpc3Qgc2F5Pwo+Pj4KPj4+Pj4KPj4+Pj4+IFsxXSBodHRwczovL2xvcmUua2VybmVsLm9yZy9s a21sLzIwMjIwNjE3MDcwNTU1LjM0NDM2OC0xLTIxY25iYW9AZ21haWwuY29tLwo+Pj4+Pj4gU2ln bmVkLW9mZi1ieTogQmFvbGluIFdhbmcgPGJhb2xpbi53YW5nQGxpbnV4LmFsaWJhYmEuY29tPgo+ Pj4+Pj4gLS0tCj4+Pj4+PiAgIGFyY2gvYXJtNjQvaW5jbHVkZS9hc20vcGd0YWJsZS5oIHwgMzEg KysrKysrKysrKysrKysrKy0tLS0tLS0tLS0tLS0tLQo+Pj4+Pj4gICAxIGZpbGUgY2hhbmdlZCwg MTYgaW5zZXJ0aW9ucygrKSwgMTUgZGVsZXRpb25zKC0pCj4+Pj4+Pgo+Pj4+Pj4gZGlmZiAtLWdp dCBhL2FyY2gvYXJtNjQvaW5jbHVkZS9hc20vcGd0YWJsZS5oIGIvYXJjaC9hcm02NC9pbmNsdWRl L2FzbS9wZ3RhYmxlLmgKPj4+Pj4+IGluZGV4IDBiZDE4ZGU5ZmQ5Ny4uMjk3OWQ3OTZiYTlkIDEw MDY0NAo+Pj4+Pj4gLS0tIGEvYXJjaC9hcm02NC9pbmNsdWRlL2FzbS9wZ3RhYmxlLmgKPj4+Pj4+ ICsrKyBiL2FyY2gvYXJtNjQvaW5jbHVkZS9hc20vcGd0YWJsZS5oCj4+Pj4+PiBAQCAtOTA1LDIx ICs5MDUsMjIgQEAgc3RhdGljIGlubGluZSBpbnQgcHRlcF90ZXN0X2FuZF9jbGVhcl95b3VuZyhz dHJ1Y3Qgdm1fYXJlYV9zdHJ1Y3QgKnZtYSwKPj4+Pj4+ICAgc3RhdGljIGlubGluZSBpbnQgcHRl cF9jbGVhcl9mbHVzaF95b3VuZyhzdHJ1Y3Qgdm1fYXJlYV9zdHJ1Y3QgKnZtYSwKPj4+Pj4+ICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHVuc2lnbmVkIGxvbmcgYWRk cmVzcywgcHRlX3QgKnB0ZXApCj4+Pj4+PiAgIHsKPj4+Pj4+IC0gICAgICAgaW50IHlvdW5nID0g cHRlcF90ZXN0X2FuZF9jbGVhcl95b3VuZyh2bWEsIGFkZHJlc3MsIHB0ZXApOwo+Pj4+Pj4gLQo+ Pj4+Pj4gLSAgICAgICBpZiAoeW91bmcpIHsKPj4+Pj4+IC0gICAgICAgICAgICAgICAvKgo+Pj4+ Pj4gLSAgICAgICAgICAgICAgICAqIFdlIGNhbiBlbGlkZSB0aGUgdHJhaWxpbmcgRFNCIGhlcmUg c2luY2UgdGhlIHdvcnN0IHRoYXQgY2FuCj4+Pj4+PiAtICAgICAgICAgICAgICAgICogaGFwcGVu IGlzIHRoYXQgYSBDUFUgY29udGludWVzIHRvIHVzZSB0aGUgeW91bmcgZW50cnkgaW4gaXRzCj4+ Pj4+PiAtICAgICAgICAgICAgICAgICogVExCIGFuZCB3ZSBtaXN0YWtlbmx5IHJlY2xhaW0gdGhl IGFzc29jaWF0ZWQgcGFnZS4gVGhlCj4+Pj4+PiAtICAgICAgICAgICAgICAgICogd2luZG93IGZv ciBzdWNoIGFuIGV2ZW50IGlzIGJvdW5kZWQgYnkgdGhlIG5leHQKPj4+Pj4+IC0gICAgICAgICAg ICAgICAgKiBjb250ZXh0LXN3aXRjaCwgd2hpY2ggcHJvdmlkZXMgYSBEU0IgdG8gY29tcGxldGUg dGhlIFRMQgo+Pj4+Pj4gLSAgICAgICAgICAgICAgICAqIGludmFsaWRhdGlvbi4KPj4+Pj4+IC0g ICAgICAgICAgICAgICAgKi8KPj4+Pj4+IC0gICAgICAgICAgICAgICBmbHVzaF90bGJfcGFnZV9u b3N5bmModm1hLCBhZGRyZXNzKTsKPj4+Pj4+IC0gICAgICAgfQo+Pj4+Pj4gLQo+Pj4+Pj4gLSAg ICAgICByZXR1cm4geW91bmc7Cj4+Pj4+PiArICAgICAgIC8qCj4+Pj4+PiArICAgICAgICAqIFRo aXMgY29tbWVudCBpcyBib3Jyb3dlZCBmcm9tIHg4NiwgYnV0IGFwcGxpZXMgZXF1YWxseSB0byBB Uk02NDoKPj4+Pj4+ICsgICAgICAgICoKPj4+Pj4+ICsgICAgICAgICogQ2xlYXJpbmcgdGhlIGFj Y2Vzc2VkIGJpdCB3aXRob3V0IGEgVExCIGZsdXNoIGRvZXNuJ3QgY2F1c2UKPj4+Pj4+ICsgICAg ICAgICogZGF0YSBjb3JydXB0aW9uLiBbIEl0IGNvdWxkIGNhdXNlIGluY29ycmVjdCBwYWdlIGFn aW5nIGFuZAo+Pj4+Pj4gKyAgICAgICAgKiB0aGUgKG1pc3Rha2VuKSByZWNsYWltIG9mIGhvdCBw YWdlcywgYnV0IHRoZSBjaGFuY2Ugb2YgdGhhdAo+Pj4+Pj4gKyAgICAgICAgKiBzaG91bGQgYmUg cmVsYXRpdmVseSBsb3cuIF0KPj4+Pj4+ICsgICAgICAgICoKPj4+Pj4+ICsgICAgICAgICogU28g YXMgYSBwZXJmb3JtYW5jZSBvcHRpbWl6YXRpb24gZG9uJ3QgZmx1c2ggdGhlIFRMQiB3aGVuCj4+ Pj4+PiArICAgICAgICAqIGNsZWFyaW5nIHRoZSBhY2Nlc3NlZCBiaXQsIGl0IHdpbGwgZXZlbnR1 YWxseSBiZSBmbHVzaGVkIGJ5Cj4+Pj4+PiArICAgICAgICAqIGEgY29udGV4dCBzd2l0Y2ggb3Ig YSBWTSBvcGVyYXRpb24gYW55d2F5LiBbIEluIHRoZSByYXJlCj4+Pj4+PiArICAgICAgICAqIGV2 ZW50IG9mIGl0IG5vdCBnZXR0aW5nIGZsdXNoZWQgZm9yIGEgbG9uZyB0aW1lIHRoZSBkZWxheQo+ Pj4+Pj4gKyAgICAgICAgKiBzaG91bGRuJ3QgcmVhbGx5IG1hdHRlciBiZWNhdXNlIHRoZXJlJ3Mg bm8gcmVhbCBtZW1vcnkKPj4+Pj4+ICsgICAgICAgICogcHJlc3N1cmUgZm9yIHN3YXBvdXQgdG8g cmVhY3QgdG8uIF0KPj4+Pj4+ICsgICAgICAgICovCj4+Pj4+PiArICAgICAgIHJldHVybiBwdGVw X3Rlc3RfYW5kX2NsZWFyX3lvdW5nKHZtYSwgYWRkcmVzcywgcHRlcCk7Cj4+Pj4+PiAgIH0KPj4+ Pj4+Cj4+Pj4+PiAgICNpZmRlZiBDT05GSUdfVFJBTlNQQVJFTlRfSFVHRVBBR0UKPj4+Pj4+IC0t Cj4+Pj4+PiAyLjM5LjMKPj4+Pj4+Cj4+Pj4+Cj4+Pj4+IFRoYW5rcwo+Pj4+PiBCYXJyeQo+Pj4K Pj4gVGhhbmtzCj4+IEJhcnJ5CgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXwpsaW51eC1hcm0ta2VybmVsIG1haWxpbmcgbGlzdApsaW51eC1hcm0ta2VybmVs QGxpc3RzLmluZnJhZGVhZC5vcmcKaHR0cDovL2xpc3RzLmluZnJhZGVhZC5vcmcvbWFpbG1hbi9s aXN0aW5mby9saW51eC1hcm0ta2VybmVsCg== 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 0FB04C25B48 for ; Wed, 25 Oct 2023 02:53:17 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8144A6B030A; Tue, 24 Oct 2023 22:53:17 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7C3C26B030B; Tue, 24 Oct 2023 22:53:17 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6B2506B030C; Tue, 24 Oct 2023 22:53:17 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 5AFE76B030A for ; Tue, 24 Oct 2023 22:53:17 -0400 (EDT) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 27190B5F11 for ; Wed, 25 Oct 2023 02:53:17 +0000 (UTC) X-FDA: 81382462434.01.3A3173D Received: from out199-14.us.a.mail.aliyun.com (out199-14.us.a.mail.aliyun.com [47.90.199.14]) by imf30.hostedemail.com (Postfix) with ESMTP id CBF7C80005 for ; Wed, 25 Oct 2023 02:53:14 +0000 (UTC) Authentication-Results: imf30.hostedemail.com; dkim=none; spf=pass (imf30.hostedemail.com: domain of baolin.wang@linux.alibaba.com designates 47.90.199.14 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=1698202395; 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=/3HJMmluLohvZkT31ayRvFegjkfYl4QdgVW1QIBPXEE=; b=b/7EJpbMGgn3BqlJlL9x+xJGOlqfx86RNuLND8rw0UaW5+Mp84hELZzt+cpnf85nvM00km QIdFjb/esQEBaylBezbnSrbyscQmsVH6GGdZkVyzKUzewWB0i3RZdXm+USz68OiBf/RiS3 K75RlUKw8unnV4dAnCrOMeABpV4a/84= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1698202395; a=rsa-sha256; cv=none; b=I3balzR4AsB+sZl2UgYvNhRZDMu57xhtkO7ZBXxL0OF3kyuUAPtsooSiZuXCdthsqMvSql eEJ/BKBdpZeXbjDfpiNE+t69efa3DLxk/eMUlkUgVXiKg8wOjpeJynEBpCqCbbQs24gS6f TutPEuv46y4eB24K30VbbrPhshXRc34= ARC-Authentication-Results: i=1; imf30.hostedemail.com; dkim=none; spf=pass (imf30.hostedemail.com: domain of baolin.wang@linux.alibaba.com designates 47.90.199.14 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=01201311R721e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=ay29a033018045176;MF=baolin.wang@linux.alibaba.com;NM=1;PH=DS;RN=10;SR=0;TI=SMTPD_---0Vusq8o5_1698201785; Received: from 30.97.48.63(mailfrom:baolin.wang@linux.alibaba.com fp:SMTPD_---0Vusq8o5_1698201785) by smtp.aliyun-inc.com; Wed, 25 Oct 2023 10:43:06 +0800 Message-ID: Date: Wed, 25 Oct 2023 10:43:21 +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: Alistair Popple , 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: <87y1frqz2u.fsf@nvdebian.thelocal> <87ttqfqw8f.fsf@nvdebian.thelocal> From: Baolin Wang In-Reply-To: <87ttqfqw8f.fsf@nvdebian.thelocal> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: CBF7C80005 X-Rspam-User: X-Stat-Signature: yo44uge7tm4jnzwi3ppm3qesxsetpxct X-Rspamd-Server: rspam03 X-HE-Tag: 1698202394-284512 X-HE-Meta: U2FsdGVkX18w7nStRZlyPo6OZ8vmKyk/NogeM/a8HcL7aAk7JX8cNcMdAg3dEmt3GRbmKp0ItNEJBxRfrvoLwkSeeOTuO8d6mKL9vhftVXMMF9WJaLLxf8RQVakUkuQJGf+X/9ttVnVT8cN5b5hHdMRjAD/oeuhduAXpF0GumZGv9BQMpeQL1Hfo03zbGyqv1SKrCL+GUrFe6EBMft/tixneG16dp69UYJC4Oi6nAzm1OTn//YatwMgwrCrB4zAomVGVMT+9A3q5Eigan63Ju0JVHpv1GBY9HXI5n4xEK02PT9DrN5WDMFpburj4O3iTlX0nL1XiroBRqkXs2PEhEPEAxkYwFKrrJnRkHScyTH59I1+ztA0Wm0JrrGNPHm+THQTRzqT1JTImCxVCbaGc0lD39WG8V/JblsfWi2zdgccqiPsxiH+aahYctJlA5f43QyA2978t66rtFADCims0zZC+tB3m5efM0vz4qf1J/8fdXnc3ul51URkpKqTam+xuHNwKsH45qya+D4lL/UwzLaKAEhg/AVbsZeVMOYQljs8RTefgt4ZdPIgAISD8kVFzBQHR7I4yEg3hSrSa5bPlgUr3sAYoPBXpOygGFaV6o87CXAdZrNz+x8D+klJWf/jwQGNpP18bpYJK3S5GF2kq/nMVPIwTP+/CSEiRHXYbPpy0B0QP7cQ49cqASL0HIpPtTyEYtm3FOHVXlnINIrQeDfB2n4rsOf5IxcsUuPGJuNg/rl5Uy7E+2eTgXqenQkzYJOA/xnClIgFdbjtP+ksMsux0WmiNrgIH2OQOVT/F/veN0ROGm0tGDTOdw8tvtgatoKSiIDciGpcSAzZCTapic97r5nkqbO+eltwfZhuUer7edBhE+JqVu7nptyP9ZZ42r9+ram5eJxnN7EQ8PSUZAP9Pvc9p1haEPnhvlFhDZEAmX2PsAB7KKQKCXJ18F5OOt+4MGWq3lUFuNtcDH6L LYAwxcyU q+yqBNRDak72IlTeVZOYtIlSZOQg98lCKqoEF3B2djZ00QkMfByRFWkfRfC29BqE+uE+pmdx0LJQprDh8P/xUXPyFJqrsfurZMzY2bHVhiX9PPfXgomJJ9YwC8Yakzrc+R/xIEl6PKNAarpsQ5x4dcRWO0s0y5EtW2eQDzC6EdeUVXCQ9rmosMZ3p283v/8UzpzzC3JyW5cnndlhz7DIV2T3cZA== 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 9:58 AM, Alistair Popple wrote: > > Barry Song <21cnbao@gmail.com> writes: > >> On Wed, Oct 25, 2023 at 9:18 AM Alistair Popple wrote: >>> >>> >>> Barry Song <21cnbao@gmail.com> writes: >>> >>>> On Wed, Oct 25, 2023 at 7:16 AM Barry Song <21cnbao@gmail.com> wrote: >>>>> >>>>> On Tue, Oct 24, 2023 at 8:57 PM Baolin Wang >>>>> wrote: > > [...] > >>>>> (A). Constant flush cost vs. (B). very very occasional reclaimed hot >>>>> page, B might >>>>> be a correct choice. >>>> >>>> Plus, I doubt B is really going to happen. as after a page is promoted to >>>> the head of lru list or new generation, it needs a long time to slide back >>>> to the inactive list tail or to the candidate generation of mglru. the time >>>> should have been large enough for tlb to be flushed. If the page is really >>>> hot, the hardware will get second, third, fourth etc opportunity to set an >>>> access flag in the long time in which the page is re-moved to the tail >>>> as the page can be accessed multiple times if it is really hot. >>> >>> This might not be true if you have external hardware sharing the page >>> tables with software through either HMM or hardware supported ATS >>> though. >>> >>> In those cases I think it's much more likely hardware can still be >>> accessing the page even after a context switch on the CPU say. So those >>> pages will tend to get reclaimed even though hardware is still actively >>> using them which would be quite expensive and I guess could lead to >>> thrashing as each page is reclaimed and then immediately faulted back >>> in. That's possible, but the chance should be relatively low. At least on x86, I have not heard of this issue. >> i am not quite sure i got your point. has the external hardware sharing cpu's >> pagetable the ability to set access flag in page table entries by >> itself? if yes, >> I don't see how our approach will hurt as folio_referenced can notify the >> hardware driver and the driver can flush its own tlb. If no, i don't see >> either as the external hardware can't set access flags, that means we >> have ignored its reference and only knows cpu's access even in the current >> mainline code. so we are not getting worse. >> >> so the external hardware can also see cpu's TLB? or cpu's tlb flush can >> also broadcast to external hardware, then external hardware sees the >> cleared access flag, thus, it can set access flag in page table when the >> hardware access it? If this is the case, I feel what you said is true. > > Perhaps it would help if I gave a concrete example. Take for example the > ARM SMMU. It has it's own TLB. Invalidating this TLB is done in one of > two ways depending on the specific HW implementation. > > If broadcast TLB maintenance (BTM) is supported it will snoop CPU TLB > invalidations. If BTM is not supported it relies on SW to explicitly > forward TLB invalidations via MMU notifiers. On our ARM64 hardware, we rely on BTM to maintain TLB coherency. > Now consider the case where some external device is accessing mappings > via the SMMU. The access flag will be cached in the SMMU TLB. If we > clear the access flag without a TLB invalidate the access flag in the > CPU page table will not get updated because it's already set in the SMMU > TLB. > > As an aside access flag updates happen in one of two ways. If the SMMU > HW supports hardware translation table updates (HTTU) then hardware will > manage updating access/dirty flags as required. If this is not supported > then SW is relied on to update these flags which in practice means > taking a minor fault. But I don't think that is relevant here - in > either case without a TLB invalidate neither of those things will > happen. > > I suppose drivers could implement the clear_flush_young() MMU notifier > callback (none do at the moment AFAICT) but then won't that just lead to > the opposite problem - that every page ever used by an external device > remains active and unavailable for reclaim because the access flag never > gets cleared? I suppose they could do the flush then which would ensure Yes, I think so too. The reason there is currently no problem, perhaps I think, there are no actual use cases at the moment? At least on our Alibaba's fleet, SMMU and MMU do not share page tables now. > the page is marked inactive if it's not referenced between the two > folio_referenced calls(). > > But that requires changes to those drivers. SMMU from memory doesn't > even register for notifiers if BTM is supported. > > - Alistair > >>> >>> Of course TLB flushes are equally (perhaps even more) expensive for this >>> kind of external HW so reducing them would still be beneficial. I wonder >>> if there's some way they could be deferred until the page is moved to >>> the inactive list say? >>> >>>>> >>>>>> [1] https://lore.kernel.org/lkml/20220617070555.344368-1-21cnbao@gmail.com/ >>>>>> Signed-off-by: Baolin Wang >>>>>> --- >>>>>> arch/arm64/include/asm/pgtable.h | 31 ++++++++++++++++--------------- >>>>>> 1 file changed, 16 insertions(+), 15 deletions(-) >>>>>> >>>>>> 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); >>>>>> } >>>>>> >>>>>> #ifdef CONFIG_TRANSPARENT_HUGEPAGE >>>>>> -- >>>>>> 2.39.3 >>>>>> >>>>> >>>>> Thanks >>>>> Barry >>> >> Thanks >> Barry