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>
CC:     Ashish Mhetre <amhetre@nvidia.com>,
        "mark.rutland@arm.com" <mark.rutland@arm.com>,
        "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>,
        "linux-arm-kernel@lists.infradead.org" 
        <linux-arm-kernel@lists.infradead.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: AQHUb2mK2jioXCSBXUOglXMUWPpsLKU2DOwAgABGE2iAN2VlVIAEmdOAgAAC4fGAABP4tw==
Date:   Thu, 6 Dec 2018 20:42:03 +0000
Message-ID: <BYAPR12MB27120C304F7B085A0CA36124CFA90@BYAPR12MB2712.namprd12.prod.outlook.com>
References: <1540805158-618-1-git-send-email-amhetre@nvidia.com>
 <20181029105515.GD14127@arm.com>
 <BN7PR12MB2708B742FD3448589AD0F259CFF30@BN7PR12MB2708.namprd12.prod.outlook.com>
 <BYAPR12MB27129A4EE7BBF57B1CAB5094CFAE0@BYAPR12MB2712.namprd12.prod.outlook.com>,<20181206191850.GC20796@arm.com>,<BYAPR12MB271239AAF4A0B79D756850C6CFA90@BYAPR12MB2712.namprd12.prod.outlook.com>
In-Reply-To: <BYAPR12MB271239AAF4A0B79D756850C6CFA90@BYAPR12MB2712.namprd12.prod.outlook.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: c612f387-613d-44a6-d365-08d65bbb4791
X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Dec 2018 20:42:03.5293
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 43083d15-7273-40c1-b7db-39efd9ccc17a
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR12MB3543
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=1544128924; bh=1uMhDSNOvnaphndMUqo9jMVAJCi++zN1c8Ilihedq+k=;
        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-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=GKn16Qt/WohOQAqnsjKgCHgGf2CcHE3+KjWrhkLKPt+g0L+ukcgPt5AygoRCxz1rb
         xI5sYy/bYpV4LU2hBoYTVPFXWVysivLebKHUKzwiAED5w8hGxm+eU+HNp8Tyc8HaP6
         r4jYxKyl9l7HIaP6y4mFarh3jgqq4bof1zav9LosXLQgFBXTVQlzm90V09X5fLMNSd
         WrmxM/cExbrDdouTBuxr5wy6Q+yczWaL24XgJpMTGMRkUWd8NLBWfTqXc75qt9nmu8
         7WZ7dvITf0FF+8jpA1KiuOi7Iou8EcaftAIRXds9HOhA8fbA1Oyq0Vz24Tu8S70sHr
         Sj7TCC/X6faQg==
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, wha=
t sort of
> > >=A0performance does that get you?
> >=20
> > It is not as good. In some cases, it is really bad. Skipping the invali=
date was
> > the most consistent and fast implementation.

> My problem with that is it's not really much different to just skipping t=
he
> page table update entirely. Skipping the DSB is closer to what is done on
> x86, where we bound the stale entry time to the next context-switch.

Which of the three implementations is the "that" and "it" in the first sent=
ence?

> Given that I already queued the version without the DSB, we have the choi=
ce
> to either continue with that or to revert it and go back to the previous
>=A0behaviour. Which would you prefer?

To me, skipping the DSB is a win over doing the invalidate and the DSB beca=
use
it is faster on average.

DSBs have a big impact on the performance of other CPUs in the inner sharea=
ble
domain because of the ordering requirements. For example, we have observed
Cortex A57s stalling all CPUs in the cluster until Device accesses complete=
.

Would you be open to a patch on top of the DSB skipping patch that skips th=
e
whole invalidate?=