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 A16E4C021B2 for ; Thu, 20 Feb 2025 15:29:57 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 021782802F9; Thu, 20 Feb 2025 10:29:57 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id F121D2802F8; Thu, 20 Feb 2025 10:29:56 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DB29D2802F9; Thu, 20 Feb 2025 10:29:56 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id BBC172802F8 for ; Thu, 20 Feb 2025 10:29:56 -0500 (EST) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 7832EA493E for ; Thu, 20 Feb 2025 15:29:56 +0000 (UTC) X-FDA: 83140708392.13.8701B0C Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.223.131]) by imf18.hostedemail.com (Postfix) with ESMTP id D02521C000F for ; Thu, 20 Feb 2025 15:29:53 +0000 (UTC) Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=LXDuCBOw; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=YADQiCNc; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=LXDuCBOw; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=YADQiCNc; dmarc=none; spf=pass (imf18.hostedemail.com: domain of vbabka@suse.cz designates 195.135.223.131 as permitted sender) smtp.mailfrom=vbabka@suse.cz ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1740065394; a=rsa-sha256; cv=none; b=0LFMUAS5VN1COAch8IVUkjg56Qsue2InREvce5dg5fjrSkup3vRbEL0I4OfxGNkHthMcy+ DH+0ResGGS9Qces5aU24lEREWEFDDw+FXHi1f3h+lp64KxZLqCv5b9TCWcPbZIG9w5Vwwe NHSHQQcUJ57wPKPEHAwxlk7wsX1fqMs= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=LXDuCBOw; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=YADQiCNc; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=LXDuCBOw; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=YADQiCNc; dmarc=none; spf=pass (imf18.hostedemail.com: domain of vbabka@suse.cz designates 195.135.223.131 as permitted sender) smtp.mailfrom=vbabka@suse.cz ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1740065394; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=Jb/RiXD5g13iqlSAPF/HYk9tHqQ8XfmsjURlIeRYP/Q=; b=khXEv4SZmHRSFzbB3kRG+8aWTcAUo30gMDJwNtqpgOXt7cFez2D5pC2mFa4POqSni90TOO 9mle7R6n/Jrlw/Q6o7gwo4Z4Kw6DGBU2KnrqwwAPM7cYFbW58Ys/TU+aVTooi0WkXhul7p SpjcZ2zN82/JQlMF00Qq6tcWNZOIuEM= Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org [IPv6:2a07:de40:b281:104:10:150:64:97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id C976A1F388; Thu, 20 Feb 2025 15:29:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1740065391; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Jb/RiXD5g13iqlSAPF/HYk9tHqQ8XfmsjURlIeRYP/Q=; b=LXDuCBOwLJdOU9mRDC8iZyUj4WjiNAYn0c7Ns1bnPyI6/2I+8XU7iuidBMvNd3xgXc6Y/a rcozu9trtwVN1pPTmo/BWRP9yxOEdK4kTISj6+VOFyjWCjQ9UGKm/S5F48p59xSty9oRke oGc5iMCeF4skiF17wt1dIVk8DqjztWU= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1740065391; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Jb/RiXD5g13iqlSAPF/HYk9tHqQ8XfmsjURlIeRYP/Q=; b=YADQiCNc2q6Bb7vt9PEO8WgpwL4fzRBf1RbCsPMM1EDvMgo7UQWJv9Gs+HU26YTA4zKkA9 bstIXxngQXRAO7Cg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1740065391; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Jb/RiXD5g13iqlSAPF/HYk9tHqQ8XfmsjURlIeRYP/Q=; b=LXDuCBOwLJdOU9mRDC8iZyUj4WjiNAYn0c7Ns1bnPyI6/2I+8XU7iuidBMvNd3xgXc6Y/a rcozu9trtwVN1pPTmo/BWRP9yxOEdK4kTISj6+VOFyjWCjQ9UGKm/S5F48p59xSty9oRke oGc5iMCeF4skiF17wt1dIVk8DqjztWU= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1740065391; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Jb/RiXD5g13iqlSAPF/HYk9tHqQ8XfmsjURlIeRYP/Q=; b=YADQiCNc2q6Bb7vt9PEO8WgpwL4fzRBf1RbCsPMM1EDvMgo7UQWJv9Gs+HU26YTA4zKkA9 bstIXxngQXRAO7Cg== Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id A240213A42; Thu, 20 Feb 2025 15:29:51 +0000 (UTC) Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167]) by imap1.dmz-prg2.suse.org with ESMTPSA id P6hJJ29Kt2ficAAAD6G6ig (envelope-from ); Thu, 20 Feb 2025 15:29:51 +0000 Message-ID: Date: Thu, 20 Feb 2025 16:29:51 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC PATCH v12 00/26] LUF(Lazy Unmap Flush) reducing tlb numbers over 90% Content-Language: en-US To: Dave Hansen , Byungchul Park , linux-kernel@vger.kernel.org, linux-mm@kvack.org Cc: kernel_team@skhynix.com, akpm@linux-foundation.org, ying.huang@intel.com, vernhao@tencent.com, mgorman@techsingularity.net, hughd@google.com, willy@infradead.org, 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 References: <20250220052027.58847-1-byungchul@sk.com> <8accbd91-ca59-43f8-b190-7e1ac3df5e11@intel.com> From: Vlastimil Babka In-Reply-To: <8accbd91-ca59-43f8-b190-7e1ac3df5e11@intel.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Action: no action X-Rspam-User: X-Rspamd-Queue-Id: D02521C000F X-Rspamd-Server: rspam12 X-Stat-Signature: u8midmzwg1oqph1tri36jnk867ttdukb X-HE-Tag: 1740065393-508734 X-HE-Meta: U2FsdGVkX1+C/TmZs/juLaYx3SAVfKd9BOzUwipy5TCclR1TO5NDZ0qKJJZY8zWkLDEbZcG+kfoQd8a0zNTREPWbbl6MG9ud7+XlA4Srg8F8q0SK0vzia5fYdBaP7Ahm+O401xCZZ8SV3H/ncojGoXxom31vDUZXhXeEkk5/U6VRHn6SZSzjZFr1GUXnye50AKrJio+AsULjFy4tRKPFBMeIW+UggiQA4MIQShZZbAx8guy98+HY5VO9yvJNDVAqYo4b6cKgA/ltJzkYiJtn6ab69tVIOIsbUYeNVmxmb1gnEOn0cK/1IqE1Nika2ewnL1CPlIlCOJER2zwQweIDsWvior6/0G1iJAMNGgGJB1tPYyVDx6ck1N0x9sBpYOH6NKQ+MeBRLMq0Fh0I8YueV6EddlC1dmwXBBQAWJs1gMWKNEPnRx61Fwxq7UV9wp0HmX+bM9q7PWjh9Nj7n7lKfOyf2sZQH7B1oPkkcxYaQ1fU9SREmyQaImIitWqXXgHrqM062gELQwW5qJV2se8DvVholhidRnL4u5NpPPZJQy4YGqiKAlJLAUmvv5v0hSmdhMUz4DEuI4S8+5O9H2rKBMFM+XVF13ygt6QTP5MH87z6qPIKMV0t14SHLRiEAPIo0MVLdh061px+yE6g5Y8hxZ9TwYUxcDpxv8ngQKfQGuUEdbHTRtSdbon4TTX3YtzzCbO4MVTElFUVaCJk1upkdpEu9q2vTk/dLy2R4ygp5UGdNYSFEqtL1RK1k3fO2d8FxVmo5OcTRO7OVydKyr486vOjRZeeMbiVVZ3zP9VFkfY+pMK0ctYuxqU2/iKZpbGiIhQMSGg0lbW6Zbzd4uQXV56K3+4OobYSJEws3PZfyXcNO2sU5KW/3v/+ZfVwpgRxk/2VFRDJdbxcyvw0ylPbYfShjIIxS/EjVTeQ7b3PqQ8ykudrmlwq6ZjCDth2Cr3tQChhtV94KSGAvZ5Yhd9 h4m6HS/G UysTF0TbaMXrqSiGENgqrdb1khTTA1LW7uee1tAoBi/cDzjfVIvxy1YjH53KpVwowQp9JQ8oAjrAl+LFGqOinVzkXVR9qFNn5QWGEnyYD5YdFMqA27uBk9wRAl2MzWURngV7g17OT4VoCN+0lmkwlgTAKPzlR0CXfidWmCqCnUkm30S/eEC6ULToD+2v5YPQj6DBMFH4yCN2OoiePxUcYVMpsnAhmis0vrRzD8p8FQbPF9C1DJd/ej3lD8uApIvT4LcLaWCrW7+NbaUwleR5L3ETRQRVFQzjqZ1ZjufM+XBWmwuf5tFlJ7tPAIpax/XM/fAxC35etSu3O7Ir9OKGN22GJyg== 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 2/20/25 16:15, Dave Hansen wrote: > On 2/19/25 21:20, Byungchul Park wrote: >> I'm posting the latest version so that anyone can try luf mechanism if >> wanted by any chance. However, I tagged RFC again because there are >> still issues that should be resolved to merge to mainline: > > I don't see anything fundamentally different here from the last 11 > versions. I think the entire approach is dangerous and basically makes > things impossible to debug. It's not clear that some of the failure > scenarios that I've brought up in the past have actually been fixed. Yes, and it's still an invasive change to the buddy allocator. IIRC at Plumbers the opinion in the audience was that there might be ways to improve the batching on unmap to reduce the flushes without such an invasive and potentially dangerous change? Has that been investigated? Also "Rebase on akpm/mm.git mm-unstable(5a7056135b) as of Nov 22, 2024." is very outdated at this point? Thanks, Vlastimil > What I've said here still stands: > >> https://lore.kernel.org/all/fab1dd64-c652-4160-93b4-7b483a8874da@intel.com/ > >> I think tglx would call all of this "tinkering". The approach to this >> series is to "fix" narrow, specific cases that reviewers point out, make >> it compile, then send it out again, hoping someone will apply it. >> >> So, for me, until the approach to this series changes: NAK, for x86. >> Andrew, please don't take this series. Or, if you do, please drop the >> patch enabling it on x86. > > I think I'd also like to stop being cc'd on this. If LUF is merged into > mainline and proven to work on arm64 or riscv for a year, I'd be happy > to take another look at enabling it on x86. I think that's just about > the only thing that would make me reconsider. >