Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
From:   Alexander Van Brunt <avanbrunt@nvidia.com>
To:     Will Deacon <will.deacon@arm.com>,
        Ashish Mhetre <amhetre@nvidia.com>
CC:     "mark.rutland@arm.com" <mark.rutland@arm.com>,
        "linux-arm-kernel@lists.infradead.org" 
        <linux-arm-kernel@lists.infradead.org>,
        "linux-tegra@vger.kernel.org" <linux-tegra@vger.kernel.org>,
        Sachin Nikam <Snikam@nvidia.com>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH V3] arm64: Don't flush tlb while clearing the accessed bit
Thread-Topic: [PATCH V3] arm64: Don't flush tlb while clearing the accessed
 bit
Thread-Index: AQHUb2mK2jioXCSBXUOglXMUWPpsLKU2DOwAgABGE2g=
Date:   Mon, 29 Oct 2018 15:13:08 +0000
Message-ID: <BN7PR12MB2708B742FD3448589AD0F259CFF30@BN7PR12MB2708.namprd12.prod.outlook.com>
References: <1540805158-618-1-git-send-email-amhetre@nvidia.com>,<20181029105515.GD14127@arm.com>
In-Reply-To: <20181029105515.GD14127@arm.com>
Accept-Language: en-US
received-spf: None (protection.outlook.com: nvidia.com does not designate
 permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 7725b8c8-aa73-4935-b55b-08d63db108d3
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Oct 2018 15:13:08.5021
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 43083d15-7273-40c1-b7db-39efd9ccc17a
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PR12MB2787
X-OriginatorOrg: Nvidia.com
Content-Language: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nvidia.com; s=n1;
        t=1540825994; bh=dWn1mdBnKTAg611Hx+yPebJ2hZjWHxfrGtq+D3o6Jrk=;
        h=X-PGP-Universal:From:To:CC:Subject:Thread-Topic:Thread-Index:Date:
         Message-ID:References:In-Reply-To:Accept-Language:X-MS-Has-Attach:
         X-MS-TNEF-Correlator:authentication-results:x-originating-ip:
         x-ms-publictraffictype:x-microsoft-exchange-diagnostics:
         x-ms-exchange-antispam-srfa-diagnostics:
         x-forefront-antispam-report:
         x-ms-office365-filtering-correlation-id:x-microsoft-antispam:
         x-ms-traffictypediagnostic:x-microsoft-antispam-prvs:
         x-exchange-antispam-report-test:x-ms-exchange-senderadcheck:
         x-exchange-antispam-report-cfa-test:x-forefront-prvs:received-spf:
         x-microsoft-antispam-message-info:spamdiagnosticoutput:
         spamdiagnosticmetadata:MIME-Version:
         X-MS-Exchange-CrossTenant-Network-Message-Id:
         X-MS-Exchange-CrossTenant-originalarrivaltime:
         X-MS-Exchange-CrossTenant-fromentityheader:
         X-MS-Exchange-CrossTenant-id:
         X-MS-Exchange-Transport-CrossTenantHeadersStamped:X-OriginatorOrg:
         Content-Language:Content-Type:Content-Transfer-Encoding;
        b=odDaJ+BF6/3D3JlJ63SRgeteO0abUQxLUC1Yp5pVY5dHlkTMJK+27ycl42lryvylQ
         P7hXmt8Tf0LDFSPNukOb+vgY+QxkOw+SNDqKltsG5YgAUhYwHIt4DjudHFUfraqk95
         3mOX9O3dO7yD2/zyD+LOIXcqCRl148h2vIiNZtuNfJBKU/KHMsTOgHLcbb/IHJBRmW
         zzAgF3njabvPCJoBKXTXie/xWZfoaYpZd75WHHy/Pik9mDbQlzKgMUfWYv2nupNK/g
         tbjAyjHQ+ST+x41F1F0lzTFbLQ22FQ4YVLRmjmxPLDizMYYxD6P79Vix8RsL0Om7lW
         somf67zswUg8Q==
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

>=A0If we roll a TLB invalidation routine without the trailing DSB, what so=
rt of
>=A0performance does that get you?

We have been doing our testing on our Carmel CPUs. Carmel will effectively
ignore a TLB invalidate that doesn't have a DSB (until the invalidate buffe=
r
overflows). So, I expect the performance to be the same as with no TLB
invalidate, but not represent the performance of other ARMv8 CPUs


From: Will Deacon <will.deacon@arm.com>
Sent: Monday, October 29, 2018 3:55 AM
To: Ashish Mhetre
Cc: mark.rutland@arm.com; linux-arm-kernel@lists.infradead.org; linux-tegra=
@vger.kernel.org; Alexander Van Brunt; Sachin Nikam; linux-kernel@vger.kern=
el.org
Subject: Re: [PATCH V3] arm64: Don't flush tlb while clearing the accessed =
bit
=A0=20

On Mon, Oct 29, 2018 at 02:55:58PM +0530, Ashish Mhetre wrote:
> From: Alex Van Brunt <avanbrunt@nvidia.com>
>=20
> Accessed bit is used to age a page and in generic implementation there is
> flush_tlb while clearing the accessed bit.
> Flushing a TLB is overhead on ARM64 as access flag faults don't get
> translation table entries cached into TLB's. Flushing TLB is not necessar=
y
> for this. Clearing the accessed bit without flushing TLB doesn't cause da=
ta
> corruption on ARM64.
> In our case with this patch, speed of reading from fast NVMe/SSD through
> PCIe got improved by 10% ~ 15% and writing got improved by 20% ~ 40%.
> So for performance optimisation don't flush TLB when clearing the accesse=
d
> bit on ARM64.
> x86 made the same optimization even though their TLB invalidate is much
> faster as it doesn't broadcast to other CPUs.

Ok, but they may end up using IPIs so lets avoid these vague performance
claims in the log unless they're backed up with numbers.

> Please refer to:
> 'commit b13b1d2d8692 ("x86/mm: In the PTE swapout page reclaim case clear
> the accessed bit instead of flushing the TLB")'
>=20
> Signed-off-by: Alex Van Brunt <avanbrunt@nvidia.com>
> Signed-off-by: Ashish Mhetre <amhetre@nvidia.com>
> ---
>=A0 arch/arm64/include/asm/pgtable.h | 20 ++++++++++++++++++++
>=A0 1 file changed, 20 insertions(+)
>=20
> diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pg=
table.h
> index 2ab2031..080d842 100644
> --- a/arch/arm64/include/asm/pgtable.h
> +++ b/arch/arm64/include/asm/pgtable.h
> @@ -652,6 +652,26 @@ static inline int ptep_test_and_clear_young(struct v=
m_area_struct *vma,
>=A0=A0=A0=A0=A0=A0=A0 return __ptep_test_and_clear_young(ptep);
>=A0 }
>=A0=20
> +#define __HAVE_ARCH_PTEP_CLEAR_YOUNG_FLUSH
> +static inline int ptep_clear_flush_young(struct vm_area_struct *vma,
> +=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 unsigned long address, pte_t *ptep)
> +{
> +=A0=A0=A0=A0 /*
> +=A0=A0=A0=A0=A0 * On ARM64 CPUs, clearing the accessed bit without a TLB=
 flush
> +=A0=A0=A0=A0=A0 * doesn't cause data corruption. [ It could cause incorr=
ect
> +=A0=A0=A0=A0=A0 * page aging and the (mistaken) reclaim of hot pages, bu=
t the
> +=A0=A0=A0=A0=A0 * chance of that should be relatively low. ]
> +=A0=A0=A0=A0=A0 *
> +=A0=A0=A0=A0=A0 * So as a performance optimization don't flush the TLB w=
hen
> +=A0=A0=A0=A0=A0 * clearing the accessed bit, it will eventually be flush=
ed by
> +=A0=A0=A0=A0=A0 * a context switch or a VM operation anyway. [ In the ra=
re
> +=A0=A0=A0=A0=A0 * event of it not getting flushed for a long time the de=
lay
> +=A0=A0=A0=A0=A0 * shouldn't really matter because there's no real memory
> +=A0=A0=A0=A0=A0 * pressure for swapout to react to. ]

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.

If we roll a TLB invalidation routine without the trailing DSB, what sort o=
f
performance does that get you?

Will
    =