From: Nadav Amit <namit@vmware.com>
To: Peter Zijlstra <peterz@infradead.org>
CC: "open list:MEMORY MANAGEMENT" <linux-mm@kvack.org>,
        "Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
        Andrew Morton <akpm@linux-foundation.org>,
        Minchan Kim <minchan@kernel.org>, Ingo Molnar <mingo@redhat.com>,
        Russell King <linux@armlinux.org.uk>, Tony Luck <tony.luck@intel.com>,
        Martin Schwidefsky <schwidefsky@de.ibm.com>,
        "David S. Miller" <davem@davemloft.net>,
        Heiko Carstens <heiko.carstens@de.ibm.com>,
        Yoshinori Sato <ysato@users.sourceforge.jp>,
        Jeff Dike <jdike@addtoit.com>,
        "linux-arch@vger.kernel.org" <linux-arch@vger.kernel.org>
Subject: Re: [PATCH v6 6/7] mm: fix MADV_[FREE|DONTNEED] TLB flush miss
 problem
Thread-Topic: [PATCH v6 6/7] mm: fix MADV_[FREE|DONTNEED] TLB flush miss
 problem
Thread-Index: AQHTC1+TxCEaBxMZR0CSGo2awCTWD6J/NTUAgAKq2AA=
Date: Sun, 13 Aug 2017 06:14:21 +0000
Message-ID: <E340B75B-2830-4E6D-BF0A-2C58A7002CF1@vmware.com>
References: <20170802000818.4760-1-namit@vmware.com>
 <20170802000818.4760-7-namit@vmware.com>
 <20170811133020.zozuuhbw72lzolj5@hirez.programming.kicks-ass.net>
In-Reply-To: <20170811133020.zozuuhbw72lzolj5@hirez.programming.kicks-ass.net>
Accept-Language: en-US
Content-Language: en-US
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <D0DC5E77A78A8F44A29F3FB55D8F7E44@namprd05.prod.outlook.com>
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Aug 2017 06:14:21.8018
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: b39138ca-3cee-4b4a-a4d6-cd83d9dd62f0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR05MB2296
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by nfs id v7D6Eawi024393
Content-Length: 1253
Lines: 33

Peter Zijlstra <peterz@infradead.org> wrote:

> On Tue, Aug 01, 2017 at 05:08:17PM -0700, Nadav Amit wrote:
>> void tlb_finish_mmu(struct mmu_gather *tlb,
>> 		unsigned long start, unsigned long end)
>> {
>> -	arch_tlb_finish_mmu(tlb, start, end);
>> +	/*
>> +	 * If there are parallel threads are doing PTE changes on same range
>> +	 * under non-exclusive lock(e.g., mmap_sem read-side) but defer TLB
>> +	 * flush by batching, a thread has stable TLB entry can fail to flush
>> +	 * the TLB by observing pte_none|!pte_dirty, for example so flush TLB
>> +	 * forcefully if we detect parallel PTE batching threads.
>> +	 */
>> +	bool force = mm_tlb_flush_nested(tlb->mm);
>> +
>> +	arch_tlb_finish_mmu(tlb, start, end, force);
>> }
> 
> I don't understand the comment nor the ordering. What guarantees we see
> the increment if we need to?

The comment regards the problem that is described in the change-log, and a
long thread that is referenced in it. So the question is whether “I don’t
understand” means “I don’t understand” or “it is not clear enough”. I’ll
be glad to address either one - just say which.

As for the ordering - I tried to clarify it in the thread of the commit. Let
me know if it is clear now.

Regards,
Nadav