Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp1204129imm; Wed, 6 Jun 2018 12:04:31 -0700 (PDT) X-Google-Smtp-Source: ADUXVKIAdD15L0Ki7tHwujgc7gX6epEtdVz4avNzmtKqGmr0wWgrcDC0HuXn1pEjqw4u/NwmmBn3 X-Received: by 2002:a65:634a:: with SMTP id p10-v6mr2900900pgv.184.1528311871052; Wed, 06 Jun 2018 12:04:31 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1528311871; cv=none; d=google.com; s=arc-20160816; b=zuzdAX6pp4zjSdxE5CYRAtX/0guhkSuji12oiG66cbBYFGnbIS5SNQell7b8fd9ziU 1j4Fd+yqSfw4myR8kCICKZU+1+n9yrocNu5FYzpOwfq4ZJGDBTi9R+02FoHB51GHIF8B /QsNckC80+hP+QZfYoPhFOaMF5RLQb7vHs0ZvEjpJHjs4Zcn0semsxc4TMfwp9t+uMu9 jeaouveBIH8DpJB5qDFX5inpKyfVSfq+MYMkodJRxkK9pmXyO10DufBVKDwLmaxa0UKQ GoLp7OTVJcE3It7tAZHF+TkCY1JlCEZKX4Y9YANmRhqQW36kEg0VG3/qbXUpL6WiYK1p Y0Qg== 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=COkGxf3y1iNZNLFwGRknMnHWyxSyn3mkU6pInoUgAvc=; b=e9N5w0pb6COogzdZWuB8NNq9s6nhKj+NjF0U22+Ts7w8hjDGHoGqGATZj2qoaVNc96 SpU95vcng8FHWdjitCWKD5wfJeteSd9d8KsW7HIbPYo/iSnyFIgrMKfNhMgl99TKb8Dc T3pOJuaNZLS4IBCJllmJK3xz3sOQjbWWWVXz5uF4djeiODv5mDNsnwY6qCJan3KFJsc8 UuMMY5JFKiQ1CycBWc5iTtN+JlzdMkq6EMbG+kqYywil9fYH5O3SXarjddMgdgyV8B0P 3qnb2zzJf7DZXqXDD9q3vRKYZRyci1W6h70AN0wATDoDw/p7VtRYi2Ao0/26ro2Eq9iT +uiQ== 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 u2-v6si5278482pgv.335.2018.06.06.12.04.15; Wed, 06 Jun 2018 12:04:31 -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 S1753918AbeFFRr0 (ORCPT + 99 others); Wed, 6 Jun 2018 13:47:26 -0400 Received: from outbound-smtp16.blacknight.com ([46.22.139.233]:47787 "EHLO outbound-smtp16.blacknight.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752255AbeFFRrZ (ORCPT ); Wed, 6 Jun 2018 13:47:25 -0400 Received: from mail.blacknight.com (pemlinmail03.blacknight.ie [81.17.254.16]) by outbound-smtp16.blacknight.com (Postfix) with ESMTPS id 7DF431C26F3 for ; Wed, 6 Jun 2018 18:47:24 +0100 (IST) Received: (qmail 22347 invoked from network); 6 Jun 2018 17:47:24 -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); 6 Jun 2018 17:47:24 -0000 Date: Wed, 6 Jun 2018 18:47:23 +0100 From: Mel Gorman To: Nadav Amit Cc: Andrew Morton , Dave Hansen , mhocko@kernel.org, vbabka@suse.cz, Aaron Lu , linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH] mremap: Increase LATENCY_LIMIT of mremap to reduce the number of TLB shootdowns Message-ID: <20180606174723.bag3o55fvqp6nbvc@techsingularity.net> References: <20180606140255.br5ztpeqdmwfto47@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 Wed, Jun 06, 2018 at 08:55:15AM -0700, Nadav Amit wrote: > > -#define LATENCY_LIMIT (64 * PAGE_SIZE) > > +#define LATENCY_LIMIT (PMD_SIZE) > > > > unsigned long move_page_tables(struct vm_area_struct *vma, > > unsigned long old_addr, struct vm_area_struct *new_vma, > > This LATENCY_LIMIT is only used in move_page_tables() in the following > manner: > > next = (new_addr + PMD_SIZE) & PMD_MASK; > if (extent > next - new_addr) > extent = next - new_addr; > if (extent > LATENCY_LIMIT) > extent = LATENCY_LIMIT; > > If LATENCY_LIMIT is to be changed to PMD_SIZE, then IIUC the last condition > is not required, and LATENCY_LIMIT can just be removed (assuming there is no > underflow case that hides somewhere). > I see no problem removing it other than we may forget that we ever limited PTE lock hold times for any reason. I'm skeptical it will matter unless mremap-intensive workloads are a lot more common than I believe. -- Mel Gorman SUSE Labs