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 921FEC25B75 for ; Fri, 31 May 2024 22:10:10 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D50996B00A4; Fri, 31 May 2024 18:10:09 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id CD9D56B00A8; Fri, 31 May 2024 18:10:09 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B7A6C6B00A9; Fri, 31 May 2024 18:10:09 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 9940C6B00A4 for ; Fri, 31 May 2024 18:10:09 -0400 (EDT) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 22F711C2B92 for ; Fri, 31 May 2024 22:10:09 +0000 (UTC) X-FDA: 82180084938.10.5FAF9ED Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf17.hostedemail.com (Postfix) with ESMTP id C3D5C40021 for ; Fri, 31 May 2024 22:10:05 +0000 (UTC) Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=YOAb47UN; spf=none (imf17.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1717193407; 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=MkS6taIPYxq4oexTWP4Nym8gBT1BhbKY0UZv23zB09c=; b=EQrCeFMxVpQGhHbuyikAXAMzA9llJCsvHOI2QPb1IhuFgg5yn2opwNgUsvdWKOTfdaI1P8 J38wbHt5+GMnAFbBMoAX4HDyGQxoRsuTnUEqAQB2Kn8Yq5nYkpP4skkWZ/w6xU5y9Hct2p Ym1sjExlShS8XUnsHUTv0oXNvlu4jaI= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1717193407; a=rsa-sha256; cv=none; b=w9Hth9TJKwfyQNV+G7r6UOs52TsUp8+QJ2tDnrtucOV1a/zEGJgU1U5PxhS4vpzJ9wWv07 46yCMo21OLpIDfQcCagC65chlixk7M5ZMxBtlGO/V5XPRSXmqi/xIfWLfjuUmDt2zLe8jf GLM5HPWZs0Twl+TwgkrQwdvOOm2JVpc= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=YOAb47UN; spf=none (imf17.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=MkS6taIPYxq4oexTWP4Nym8gBT1BhbKY0UZv23zB09c=; b=YOAb47UNG4kr8fjujJxJLocaah gAD8nRmrJmfY16d/vHGhG/ULklZSzFjKDEQj5Jsvt6jNIBVa2xYYwK0g9e5tZ9eyi1BEkZQPMEUXu LYjXw/PsVwoiWXHEwmTlg6s8+eWAFGraVhRyXIB2rHlue3eyQU7efWdgwvMux7vX9jSJfw95vIuW0 CDxs+adDaRuBRPjULIb1qHKNhi5q4CxrlWJAisHnMltsxKLWucQZ0ynCzb0VVxreZfGYyVDv8jxs8 7Dl1Q8BGXCO/5sDZ/TqL9Q2dBpe+kPcp9lMyAsWeT25aYFO5bjLIyDsUTu3mN3M0FUC8EZqR/RFFA AyLcaXPQ==; Received: from willy by casper.infradead.org with local (Exim 4.97.1 #2 (Red Hat Linux)) id 1sDARW-0000000C4jN-2aQL; Fri, 31 May 2024 22:09:46 +0000 Date: Fri, 31 May 2024 23:09:46 +0100 From: Matthew Wilcox To: Dave Hansen Cc: Byungchul Park , Byungchul Park , linux-kernel@vger.kernel.org, linux-mm@kvack.org, kernel_team@skhynix.com, akpm@linux-foundation.org, ying.huang@intel.com, vernhao@tencent.com, mgorman@techsingularity.net, hughd@google.com, david@redhat.com, peterz@infradead.org, luto@kernel.org, tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, rjgolo@gmail.com Subject: Re: [PATCH v11 09/12] mm: implement LUF(Lazy Unmap Flush) defering tlb flush when folios get unmapped Message-ID: References: <20240531092001.30428-1-byungchul@sk.com> <20240531092001.30428-10-byungchul@sk.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspam-User: X-Stat-Signature: u7btbtmimsoue44i15xmnht6p4c33ymy X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: C3D5C40021 X-HE-Tag: 1717193405-228031 X-HE-Meta: U2FsdGVkX1/dTT6Rv8oi/uiN2MGuc2Y/LsO3lkcUCNTI5lvsxJ7H1t/2Pez1I0DRx6QROVhYK3ikGkib4c7Izb7YrAdyYQig617U40paFYDuI+SYGq/vWU43v7J6KpjSJ247kocJqM96U5cxlZlVHF1eTud0xCk9oe5yiKs5TI89JNoTDEfc25R5j5pqdiSybCqGLRXGXhXJBEkj0LvF7muCA3R7u+J0s7eS4HDVusRfNXgHdasbHdwRPsJd2wKdY1NXmleZV54nGeARokRZOy7zVWYTlmpZCCZrM20qvUWQ6hcPLIFY8ko3vtwSFEXDiQqM91FCWNtcTSxfdrT7kRN0c5Q7NvGIaRt/tA/whmFq2YtC4soBSNybybMO8GcQSZl6sQsdloGKXzuYAnrG2b6FqQ7ggyqDwQSsCLFqFJ1B1nOnhWvjddsdsit8bF48ZIvgZRKKTczngj9QMXyvWyGMcovLiafCE2Rjg1Xwzf8mZDVKhJ//taWh4OQPKVqw4iEV9VPI4iU1llft1kgm6bTeR3OJu6N04bbHScFvcHsmOVODQvqi9OrkNYhyOBS+u1FAAycJY1tJg+6Wee0GzXlHI4yaOL/xI2V1bWXQT573r7exJ8XAzLehveQCmF+6hm1tbdst5nCXyKR1wbwxlJpEzAcu/nZzIOub1AeeFXE8ii/xne/r7YAP5N9CdQ7NPCPMUuha8bEIw5oVncVTl+eH4WE+jAsJx3mV/unWqgCogKqvVqtwpPKOBA9h1X0f6r7APj3+6PlEIvAjphu7NtYyGQR0b2Zfjfm8BdTM8GKfzrk+e1+eua0121f+j4xWuhcFVCOHnPOADhinVT20VeInSNckOckBsRsK5GZv50DACg2ErZs540Sm+n2MBPtABqDEq01NjFqinlTAURexNDACUEGR4X+gdWziCKSXxlemd6sr5A8I702cHmXbReTf3CoApdRvC2aijjDqG7t AwdNCUJ1 CI86EdBlf0fdWB55Ath1OeNmuNVGwYwqQAOOCqwd71lPZAK/zp92KfJkWr0X/Jo004Jx+4Xlr9UF23KdmDYxcXnl+Tf3s1D75E97OAk2LzWhvnAeuahRvk1RkCpaHEPnVUh1ZkjxuofuQWD9icjLhkiPbDuQ9jFnz4VND/frICWzY540= 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: List-Subscribe: List-Unsubscribe: On Fri, May 31, 2024 at 02:46:23PM -0700, Dave Hansen wrote: > On 5/31/24 11:04, Byungchul Park wrote: > ... > > I don't believe you do not agree with the concept itself. Thing is > > the current version is not good enough. I will do my best by doing > > what I can do. > > More performance is good. I agree with that. > > But it has to be weighed against the risk and the complexity. The more > I look at this approach, the more I think this is not a good trade off. > There's a lot of risk and a lot of complexity and we haven't seen the > full complexity picture. The gaps are being fixed by adding complexity > in new subsystems (the VFS in this case). > > There are going to be winners and losers, and this version for example > makes file writes lose performance. > > Just to be crystal clear: I disagree with the concept of leaving stale > TLB entries in place in an attempt to gain performance. FWIW, I agree with Dave. This feels insanely dangerous and I don't think you're paranoid enough about things that can go wrong.