From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id CE18EC33CAF for ; Fri, 17 Jan 2020 01:46:29 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 949B2206D7 for ; Fri, 17 Jan 2020 01:46:29 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="YLuQ4iN8" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 949B2206D7 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linux-foundation.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 326D66B0300; Thu, 16 Jan 2020 20:46:29 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 2B1136B0301; Thu, 16 Jan 2020 20:46:29 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 19F9F6B0302; Thu, 16 Jan 2020 20:46:29 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0131.hostedemail.com [216.40.44.131]) by kanga.kvack.org (Postfix) with ESMTP id F2C836B0300 for ; Thu, 16 Jan 2020 20:46:28 -0500 (EST) Received: from smtpin25.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with SMTP id 98F4040C3 for ; Fri, 17 Jan 2020 01:46:28 +0000 (UTC) X-FDA: 76385436456.25.thumb82_559ab13f48d36 X-HE-Tag: thumb82_559ab13f48d36 X-Filterd-Recvd-Size: 3131 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf29.hostedemail.com (Postfix) with ESMTP for ; Fri, 17 Jan 2020 01:46:28 +0000 (UTC) Received: from X1 (nat-ab2241.sltdut.senawave.net [162.218.216.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 38BFA2075B; Fri, 17 Jan 2020 01:46:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1579225587; bh=kF0McEzzIna+OlNxDDvv0BFj+tanfJPabCZ9hgpDZTw=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=YLuQ4iN8bF+tZrRX09LQTvkHEz92ULIHS5nIyWSwrfb4VbMtXxH/Oe5XZvuePIEYo sF47+mV/+zMy6nfyYfcd5nDd1MXB36Ni+9+XvwIfqY6iK0mnRcIs4F6WqZkN0XwLIK SBIuF6vqcLWRDG/ZIbepRDIL+/bqD5sHlh96ZRAA= Date: Thu, 16 Jan 2020 17:46:26 -0800 From: Andrew Morton To: "Aneesh Kumar K.V" Cc: peterz@infradead.org, will@kernel.org, mpe@ellerman.id.au, linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org, linuxppc-dev@lists.ozlabs.org Subject: Re: [PATCH v4 3/9] asm-generic/tlb: Avoid potential double flush Message-Id: <20200116174626.0244f71bbff64eee6c7faa1d@linux-foundation.org> In-Reply-To: References: <20200116064531.483522-1-aneesh.kumar@linux.ibm.com> <20200116064531.483522-4-aneesh.kumar@linux.ibm.com> X-Mailer: Sylpheed 3.5.1 (GTK+ 2.24.32; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Thu, 16 Jan 2020 12:19:59 +0530 "Aneesh Kumar K.V" wrote: > On 1/16/20 12:15 PM, Aneesh Kumar K.V wrote: > > From: Peter Zijlstra > > > > Aneesh reported that: > > > > tlb_flush_mmu() > > tlb_flush_mmu_tlbonly() > > tlb_flush() <-- #1 > > tlb_flush_mmu_free() > > tlb_table_flush() > > tlb_table_invalidate() > > tlb_flush_mmu_tlbonly() > > tlb_flush() <-- #2 > > > > does two TLBIs when tlb->fullmm, because __tlb_reset_range() will not > > clear tlb->end in that case. > > > > Observe that any caller to __tlb_adjust_range() also sets at least one > > of the tlb->freed_tables || tlb->cleared_p* bits, and those are > > unconditionally cleared by __tlb_reset_range(). > > > > Change the condition for actually issuing TLBI to having one of those > > bits set, as opposed to having tlb->end != 0. > > > > > We should possibly get this to stable too along with the first two > patches. I am not quiet sure if this will qualify for a stable backport. > Hence avoided adding Cc:stable@kernel.org I'm not seeing any description of the user-visible runtime effects. Always needed, especially for -stable, please. It appears to be a small performance benefit? If that benefit was "large" and measurements were presented then that would be something we might wish to backport.