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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id E5A9BC433FE for ; Mon, 17 Oct 2022 14:57:24 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5AA086B0074; Mon, 17 Oct 2022 10:57:24 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5588D6B0075; Mon, 17 Oct 2022 10:57:24 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 447FE6B0078; Mon, 17 Oct 2022 10:57:24 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 350A96B0074 for ; Mon, 17 Oct 2022 10:57:24 -0400 (EDT) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id F32B316091E for ; Mon, 17 Oct 2022 14:57:23 +0000 (UTC) X-FDA: 80030744766.15.7A99327 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by imf03.hostedemail.com (Postfix) with ESMTP id 488B12001C for ; Mon, 17 Oct 2022 14:57:22 +0000 (UTC) Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out1.suse.de (Postfix) with ESMTP id C102E34302; Mon, 17 Oct 2022 14:57:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1666018640; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=YwPRndPIKbMGfHiI0+b6VWLwGq2HJgw8Lxgojln60d0=; b=HKcy6ZR4cdX6/c9CqhGRg4sgBXQwSPhSamrRzBggpNOrM/tvut9/JdMLFIUmb5wlS6fPOK uo/3BpWgSmEgh3TH1CfXLT+jL/8jp89dQ2gvllD/ZS+FXc1N0Yia7Zp1urELENWZd+6mpr 0D/ZFHle+DPIACKhWgMYKeRGe14e4Z8= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1666018640; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=YwPRndPIKbMGfHiI0+b6VWLwGq2HJgw8Lxgojln60d0=; b=hmgiBOoEphiWs8FNXs041Qr6u6sF6OybuJeezD2qfhPru+YQzZFSMBHfVKpNbBh3BtTFtp qjVN/enU8IxS1uBQ== Received: from suse.de (mgorman.tcp.ovpn2.nue.suse.de [10.163.32.246]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by relay2.suse.de (Postfix) with ESMTPS id AA9512C141; Mon, 17 Oct 2022 14:57:17 +0000 (UTC) Date: Mon, 17 Oct 2022 15:57:12 +0100 From: Mel Gorman To: Linus Torvalds Cc: Nadav Amit , Jann Horn , Andy Lutomirski , Linux-MM , Rik van Riel , kernel list , Kees Cook , Ingo Molnar , Sasha Levin , Andrew Morton , Will Deacon , Peter Zijlstra Subject: Re: [BUG?] X86 arch_tlbbatch_flush() seems to be lacking mm_tlb_flush_nested() integration Message-ID: <20221017145712.5tdedsrrkbopptzl@suse.de> References: <0484E294-D6D6-45CE-87F7-5AFDA5309BA1@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1666018642; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=YwPRndPIKbMGfHiI0+b6VWLwGq2HJgw8Lxgojln60d0=; b=mSrILy2ZDyqjhEF2th6Xj7XAjDsVf2z62glngauxTfVD3zdt2asvRbby+7EG/iHTYabmGJ m7D1AxC5/Qx8OokOV5xC3w0QBcY/SZydT/PsXSSRmnDzNn/hXGwf72SWajdvX5Fuz0RMoN xM/QHE8SyIHwA5hpJ7Y7PmmW7gYIdfc= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=pass header.d=suse.de header.s=susede2_rsa header.b=HKcy6ZR4; dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b=hmgiBOoE; spf=pass (imf03.hostedemail.com: domain of mgorman@suse.de designates 195.135.220.28 as permitted sender) smtp.mailfrom=mgorman@suse.de; dmarc=pass (policy=none) header.from=suse.de ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1666018642; a=rsa-sha256; cv=none; b=NNS/DhPbomGDFj5SMh0WyB9EmtFNrs9/5NNWCxa5IKOclS8+thwL00JHZeLJgzp4LfNpi+ WbBukfzQjObHOK4vOcVfj3kZsDZNdow33sNW+kex7/KDme+eJSjDPxZ/QQFhgloxtGuEYr nmHBlBO6VXkD5lC8ZbGFylpSdSDm4DQ= X-Rspamd-Server: rspam12 X-Rspam-User: Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=suse.de header.s=susede2_rsa header.b=HKcy6ZR4; dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b=hmgiBOoE; spf=pass (imf03.hostedemail.com: domain of mgorman@suse.de designates 195.135.220.28 as permitted sender) smtp.mailfrom=mgorman@suse.de; dmarc=pass (policy=none) header.from=suse.de X-Stat-Signature: aq1x6ko8k53hefh5ph5da93qp83xzo38 X-Rspamd-Queue-Id: 488B12001C X-HE-Tag: 1666018642-220110 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 Sat, Oct 15, 2022 at 04:47:16PM -0700, Linus Torvalds wrote: > On Fri, Oct 14, 2022 at 8:51 PM Nadav Amit wrote: > > > > Unless I am missing something, flush_tlb_batched_pending() is would be > > called and do the flushing at this point, no? > > Ahh, yes. > > That seems to be doing the right thing, although looking a bit more at > it, I think it might be improved. > To be fair, I originally got it wrong and Nadav caught it almost 2 years later. However, I think the current behaviour is still ok. > At least in the zap_pte_range() case, instead of doing a synchronous > TLB flush if there are pending batched flushes, it migth be better if > flush_tlb_batched_pending() would set the "need_flush_all" bit in the > mmu_gather structure. > I think setting need_flush_all would miss the case if no PTEs were updated due to a race during unmap. I think it would be safer to check for deferred TLB flush in mm_tlb_flush_nested but didn't dig too deep. > That would possibly avoid that extra TLB flush entirely - since > *normally* fzap_page_range() will cause a TLB flush anyway. > > Maybe it doesn't matter. > While it could be better, I still think the simple approach is sufficient and it can be used in each affected area. For example, move_ptes does not use mmu_gather and either that would have to be converted to use mmu_gather or have mmu_gather and !mmu_gather detection of deferred TLB flushing from reclaim context and I'm not sure it's worth it. Once reclaim is active, the performance is slightly degraded as TLBs are being flushed anyway and it's possible that active pages are being reclaimed that will have to be refaulted which is even more costly. For the scenario Jann was concerned with, pages belonging to the task are being reclaimed while mmap/munmap operations are also happening. munmap/mmap is sufficiently expensive that a spurious flush due to parallel reclaim should have negligible additional overhead and I'd be surprised if the additional runtime cost can be reliably measured. -- Mel Gorman SUSE Labs