Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp1351156imm; Tue, 5 Jun 2018 13:08:46 -0700 (PDT) X-Google-Smtp-Source: ADUXVKLAveMHX58gQ0WyUMqlSq+STsUydQa0nPD+1g5qotMk7n45dqqKUengVMeqf6CM45Rr/aAA X-Received: by 2002:a62:c16:: with SMTP id u22-v6mr55019pfi.177.1528229326028; Tue, 05 Jun 2018 13:08:46 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1528229325; cv=none; d=google.com; s=arc-20160816; b=rLasHQQu5ayUhW9G5UAQAxhS+2LgqZ2C+UK8pCUHLYnIcv0tCmifWhzde5G02+yFi7 EFrqtkgnr2/4b/SJ2LjzY2PPe3YH3ej/XSa33CqbKxOCEgjviBU8CN5hB1ZgjSNJovpT 1Avhszc8LwXc+c6Ge4JqgDFeMisuy/v3bC61FKIyFCTTCKsGV8hbJn6xD/cwSeWoP/UQ 88lZDQtSVcM3w1zBON5viL79O2subpSKr/P1D0n035ptgoS/t3SHWE6rPZOF+lI866lG usnIvGnQAfu2tDbJg5o3T3Aa1Qk9J2KXgL5R2PK/3OLybilbNSOK/vbqHSa0Pz3KY+7S viyw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=sMQcjh31ZvTtc/g28V4A4A+JwodeSmtDE31vyFY0Pzs=; b=m4+i/ZegIInAKjNMLOltYzF6ruXYRf1XA+xBzbCstMdMUtm+hvPs9h/1PCw1+D6DRx GTtCZDwUnYp+B/XrnA/DD/1QJvZkkkH2XDWvFaZYns2SCXRkWwc0HNeoPJAKvlKDxvrr lEw/zvXWBDLROnEyQDRejxdI9tOyYhbJynkrmxZMf3AvjuK+JQDG85LQyOzwSqUUkIln T8L8kDJ8gwfdS0xKX9e2KM4Zd3NVz5+fzzX973xtmZaWQKNiQl0uI0WrJ6OHhNPbJrCH OCX+jlmZl65ralCZzrYhcnGafvEajP31wXGG0WKIwrszHlUySUUOToFGtJpt592DuQcg Sxyw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id g14-v6si8347850plq.41.2018.06.05.13.08.30; Tue, 05 Jun 2018 13:08:45 -0700 (PDT) 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; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752252AbeFEUID (ORCPT + 99 others); Tue, 5 Jun 2018 16:08:03 -0400 Received: from outbound-smtp26.blacknight.com ([81.17.249.194]:35781 "EHLO outbound-smtp26.blacknight.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752050AbeFEUIC (ORCPT ); Tue, 5 Jun 2018 16:08:02 -0400 Received: from mail.blacknight.com (pemlinmail05.blacknight.ie [81.17.254.26]) by outbound-smtp26.blacknight.com (Postfix) with ESMTPS id 4114FB88A2 for ; Tue, 5 Jun 2018 21:08:01 +0100 (IST) Received: (qmail 1826 invoked from network); 5 Jun 2018 20:08:01 -0000 Received: from unknown (HELO techsingularity.net) (mgorman@techsingularity.net@[37.228.237.73]) by 81.17.254.9 with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 5 Jun 2018 20:08:01 -0000 Date: Tue, 5 Jun 2018 21:08:00 +0100 From: Mel Gorman To: Nadav Amit Cc: Andrew Morton , Michal Hocko , Vlastimil Babka , Aaron Lu , Dave Hansen , Linux Kernel Mailing List , linux-mm@kvack.org Subject: Re: [PATCH] mremap: Avoid TLB flushing anonymous pages that are not in swap cache Message-ID: <20180605200800.emb3yfdtnpjgmxb7@techsingularity.net> References: <20180605171319.uc5jxdkxopio6kg3@techsingularity.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170912 (1.9.0) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jun 05, 2018 at 12:53:57PM -0700, Nadav Amit wrote: > While I do not have a specific reservation regarding the logic, I find the > current TLB invalidation scheme hard to follow and inconsistent. I guess > should_force_flush() can be extended and used more commonly to make things > clearer. > > To be more specific and to give an example: Can should_force_flush() be used > in zap_pte_range() to set the force_flush instead of the current code? > > if (!PageAnon(page)) { > if (pte_dirty(ptent)) { > force_flush = 1; > ... > } > That check is against !PageAnon pages where it's potentially critical that the dirty PTE bit be propogated to the page. You could split the separate the TLB flush from the dirty page setting but it's not the same class of problem and without perf data, it's not clear it's worthwhile. Note that I also didn't handle the huge page moving because it's already naturally batching a larger range with a lower potential factor of TLB flushing and has different potential race conditions. I agree that the TLB handling would benefit from being simplier but it's not a simple search/replace job to deal with the different cases that apply. -- Mel Gorman SUSE Labs