From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750930AbdHMGGi (ORCPT ); Sun, 13 Aug 2017 02:06:38 -0400 Received: from mail-bl2nam02on0066.outbound.protection.outlook.com ([104.47.38.66]:42271 "EHLO NAM02-BL2-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1750813AbdHMGGg (ORCPT ); Sun, 13 Aug 2017 02:06:36 -0400 From: Nadav Amit To: Peter Zijlstra CC: Ingo Molnar , Stephen Rothwell , Andrew Morton , Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , Linux-Next Mailing List , "Linux Kernel Mailing List" , Linus , "minchan@kernel.org" Subject: Re: linux-next: manual merge of the akpm-current tree with the tip tree Thread-Topic: linux-next: manual merge of the akpm-current tree with the tip tree Thread-Index: AQHTEnbvkRXpJ0prakSqPKBRkcADs6J+5TmAgAAkogCAAALYgIAAI/cAgAKfBAA= Date: Sun, 13 Aug 2017 06:06:32 +0000 Message-ID: References: <20170811175326.36d546dc@canb.auug.org.au> <20170811093449.w5wttpulmwfykjzm@hirez.programming.kicks-ass.net> <20170811214556.322b3c4e@canb.auug.org.au> <20170811115607.p2vgqcp7w3wurhvw@gmail.com> <20170811140450.irhxa2bhdpmmhhpv@hirez.programming.kicks-ass.net> In-Reply-To: <20170811140450.irhxa2bhdpmmhhpv@hirez.programming.kicks-ass.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2601:647:4580:b719:ccc4:4166:fd5b:554e] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1;BY2PR05MB2328;20:SNXI/OeHW8KFJ1O8lfy+GjXsqIEnx+rbLWa9HBmQUW7FM5HKjyxz8yt4idujSu2yvISQmUDNI5xG549a/vnUv23uA2JU8AQ4+Yy/AiKl51KT85k9D1fZUKdKuNao7hApMmQzdHDjERoVsqeRHvdVdV+4ctIhV0WYa8Mx4BKQL/k= x-ms-office365-filtering-correlation-id: a2630c62-1255-4947-dba5-08d4e2117248 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(2017052603140)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095);SRVR:BY2PR05MB2328; x-ms-traffictypediagnostic: BY2PR05MB2328: x-exchange-antispam-report-test: UriScan:(17755550239193); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(3002001)(100000703101)(100105400095)(93006095)(93001095)(10201501046)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123555025)(20161123560025)(20161123564025)(20161123558100)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095);SRVR:BY2PR05MB2328;BCL:0;PCL:0;RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095);SRVR:BY2PR05MB2328; x-forefront-prvs: 03982FDC1D x-forefront-antispam-report: SFV:NSPM;SFS:(10009020)(6009001)(199003)(189002)(24454002)(68736007)(97736004)(76176999)(83716003)(50986999)(54356999)(229853002)(101416001)(189998001)(478600001)(7736002)(305945005)(7416002)(14454004)(2950100002)(4326008)(6916009)(25786009)(6512007)(106356001)(54906002)(2906002)(110136004)(105586002)(99286003)(102836003)(6486002)(53936002)(36756003)(5660300001)(6116002)(6436002)(8936002)(86362001)(81156014)(82746002)(93886004)(3280700002)(6246003)(33656002)(81166006)(8676002)(77096006)(6506006)(2900100001)(3660700001);DIR:OUT;SFP:1101;SCL:1;SRVR:BY2PR05MB2328;H:BY2PR05MB2215.namprd05.prod.outlook.com;FPR:;SPF:None;PTR:InfoNoRecords;A:1;MX:1;LANG:en; authentication-results: spf=none (sender IP is ) smtp.mailfrom=namit@vmware.com; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <333CCAC84D73794ABB613731DD1F7B93@namprd05.prod.outlook.com> MIME-Version: 1.0 X-OriginatorOrg: vmware.com X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Aug 2017 06:06:32.1406 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b39138ca-3cee-4b4a-a4d6-cd83d9dd62f0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR05MB2328 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by nfs id v7D66hXG024387 Peter Zijlstra wrote: > > Ok, so I have the below to still go on-top. > > Ideally someone would clarify the situation around > mm_tlb_flush_nested(), because ideally we'd remove the > smp_mb__after_atomic() and go back to relying on PTL alone. > > This also removes the pointless smp_mb__before_atomic() > > --- > Subject: mm: Fix barriers for the tlb_flush_pending thing > From: Peter Zijlstra > Date: Fri Aug 11 12:43:33 CEST 2017 > > I'm not 100% sure we always care about the same PTL and when we have > SPLIT_PTE_PTLOCKS and have RCpc locks (PPC) the UNLOCK of one does not > in fact order against the LOCK of another lock. Therefore the > documented scheme does not work if we care about multiple PTLs > > mm_tlb_flush_pending() appears to only care about a single PTL: > > - arch pte_accessible() (x86, arm64) only cares about that one PTE. > - do_huge_pmd_numa_page() also only cares about a single (huge) page. > - ksm write_protect_page() also only cares about a single page. > > however mm_tlb_flush_nested() is a mystery, it appears to care about > anything inside the range. For now rely on it doing at least _a_ PTL > lock instead of taking _the_ PTL lock. It does not care about “anything” inside the range, but only on situations in which there is at least one (same) PT that was modified by one core and then read by the other. So, yes, it will always be _the_ same PTL, and not _a_ PTL - in the cases that flush is really needed. The issue that might require additional barriers is that inc_tlb_flush_pending() and mm_tlb_flush_nested() are called when the PTL is not held. IIUC, since the release-acquire might not behave as a full memory barrier, this requires an explicit memory barrier. > Therefore add an explicit smp_mb__after_atomic() to cure things. > > Also remove the smp_mb__before_atomic() on the dec side, as its > completely pointless. We must rely on flush_tlb_range() to DTRT. Good. It seemed fishy to me, but I was focused on the TLB consistency and less on the barriers (that’s my excuse). Nadav