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 DDB00C27C55 for ; Mon, 10 Jun 2024 13:24:00 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 48B236B0083; Mon, 10 Jun 2024 09:24:00 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 43A526B0085; Mon, 10 Jun 2024 09:24:00 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2B4FB6B0088; Mon, 10 Jun 2024 09:24:00 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 0D4B56B0083 for ; Mon, 10 Jun 2024 09:24:00 -0400 (EDT) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 7FAFA1A1005 for ; Mon, 10 Jun 2024 13:23:59 +0000 (UTC) X-FDA: 82215046998.08.D6C6D8F Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.223.131]) by imf11.hostedemail.com (Postfix) with ESMTP id 6B00B4000E for ; Mon, 10 Jun 2024 13:23:56 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=ZPP+8ktl; dkim=pass header.d=suse.com header.s=susede1 header.b=ZPP+8ktl; spf=pass (imf11.hostedemail.com: domain of mhocko@suse.com designates 195.135.223.131 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1718025836; a=rsa-sha256; cv=none; b=lQO0lC2oNgXKLc8yAxLyx3TN6JoktnykGPPwwS1TYiSyz+5eH15CvyExI7SRfejeO/GkCI 2geOKQt7GxXN7KIkhV2is2IPe01OWO942I1/lKl1hzSNe2JO6Aya4qjNXRrCRJ1jEQuPcb W4F35WIDEExfimB3CGwdwDQabxzW3+g= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=ZPP+8ktl; dkim=pass header.d=suse.com header.s=susede1 header.b=ZPP+8ktl; spf=pass (imf11.hostedemail.com: domain of mhocko@suse.com designates 195.135.223.131 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1718025836; 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=zhwIXuLk75mx3LVCWaJczOVutWJ7oqAn3s5/sjvFOAQ=; b=1MKBlTFnn9d4xfyUmO8q20Cbavuc75d2P3DI6K5WHIRiH2dsC24FcPK8/ZUR+yRaB+qK3P NEkx96Psqaed5H9IZxJIj4jgB0faMXxtcw2oFhW0es7FVYhTtc7co1ifZboeDOn2Rl/S4b VBQdcTd4sXCJEIdMHxMrrvxMSShxYRw= 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 B394F1F7F3; Mon, 10 Jun 2024 13:23:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1718025834; 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=zhwIXuLk75mx3LVCWaJczOVutWJ7oqAn3s5/sjvFOAQ=; b=ZPP+8ktlXgU1i1nQ85U7YBTWOxphkzTDHferEufkD5zGTMpLQUoKciODWszBmDdOtfN9ew 4F/zOSj2bBV92seg1cqgSXgql4QksW6TUtFvYu8q3clCIDvO3P3zjPKg+Avkn/GGm9E9RK DftIQM1ebBLpqGMrs8T5ZoXdefMiWa4= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1718025834; 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=zhwIXuLk75mx3LVCWaJczOVutWJ7oqAn3s5/sjvFOAQ=; b=ZPP+8ktlXgU1i1nQ85U7YBTWOxphkzTDHferEufkD5zGTMpLQUoKciODWszBmDdOtfN9ew 4F/zOSj2bBV92seg1cqgSXgql4QksW6TUtFvYu8q3clCIDvO3P3zjPKg+Avkn/GGm9E9RK DftIQM1ebBLpqGMrs8T5ZoXdefMiWa4= 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 9401413A51; Mon, 10 Jun 2024 13:23:54 +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 peg5IWr+ZmYbMwAAD6G6ig (envelope-from ); Mon, 10 Jun 2024 13:23:54 +0000 Date: Mon, 10 Jun 2024 15:23:49 +0200 From: Michal Hocko To: Byungchul Park Cc: Matthew Wilcox , Dave Hansen , David Hildenbrand , 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, 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: <26dc4594-430b-483c-a26c-7e68bade74b0@redhat.com> <20240603093505.GA12549@system.software.com> <35866f91-7d96-462a-aa0a-ac8a6b8cbcf8@redhat.com> <196481bb-b86d-4959-b69b-21fda4daae77@intel.com> <20240604003448.GA26609@system.software.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240604003448.GA26609@system.software.com> X-Rspamd-Action: no action X-Rspamd-Queue-Id: 6B00B4000E X-Rspam-User: X-Rspamd-Server: rspam12 X-Stat-Signature: kwhfiyossua5cgexwie5xzzbp6gbr4ps X-HE-Tag: 1718025836-483425 X-HE-Meta: U2FsdGVkX1+w+Lhi8fQuPx3G0eIgvY44yMOIvulBHDibPJZ4kmUK0NmVE07MmKFK9m42VmLPUhfo6Df2MzNBLW9VC3rCxJmCbnHFwJJa8dEVPV0XaG44xnyEptR5Yofo9cGxZ5ig2f/H1d9CcC+YylpAZ0lyknDfKA1GNvY4JbxEuy8K46B3qRF6/EozzMcF7OIe6mhefJMGpk99XwU1BM60TJ/d2T28rBzymou/182jfpiIEL2BXaJIW3VTBCYlLCq1NmaztvBLpBosx6DS/aQ1LAZFULUR60a9F80LfMHdBN69jJ1Vahzkcmpdgbl6JQ+CqA1lEFc/oV7h2+G+7iSChFvA3VuvUeHmp7qcl7bOd5Yga/GCicXJnrG6oNsQ9wGTmonhaN8XUw4j6KDv2eUftkZH32J9SUT9oQJm2J6zSDc97ZgF5S17fr+FWVCKx/HixszmfxBws0/G6u6bTVdtsu5CnEhtHf/Tmie+iXkMg9NL0atIBv+/XOf5zaUQjEHa8OF/5l1HvVNGFIgeeJsyB0hS1ztU7BlQmVujoRoJVbH2FszvFRZLDkU9FqnqHXMUWx+H1FLVCZF3Qhh3jvveUxVT4Hs+fAhIf3dxih/xzcJ3yTQN2D+GrBjcuLs5A5BH7I7ltYbUbGcc10lnWQj9aN0SsaVG5KSZGyYio5f7gfDnFTitrWkLQgenaTwc584zCA45s1KiY5fS9V8tA2bu9ESRhfrEeqULsLPh+4kf/axlUR9r5biw6gpbSQp4JNdoBfe6/QdHLLwyaTZ5gzt0ckKJ//3LarwCtZRyC+eRvkrQ7bvlXI15mrJjFbD3zKi6UEK9t4/47fD8kPpt9xKI6PBf+gyfhr2TeJNtKSMScFrR/77yNQ8uUCmKlKF2MH9qy8ccPTx/BHy9vwW+Vi0RMjROf7HMzMtoOw3kQkB+KX/Q4sx2vILDzW91XxAqN84SCB2EPY/Q/YuXIrN IvQ7SOAA IkzTFgi8/UCn/EJRPLba/2gBEGWF6IRbMGSymVHgCjuKtEFiXEjOkte7V+0Yj/ssmK08+RBiPjcenG6TwMnQ1NITsAm12u75VF4H1Ct/KrmlXMY4BB/3i8NvZnnJ4eua8Hmcw3oP5NXc7quvAjb+3OzUS+ym5JiWJeer6iQZymNECz4OBnyNrPJ7ZK8L0JrwLZgKhBCxs6njDlp/s9p95ei8eYVjYBNldoYFxhwVSulCUL8lsvA/u+SufjB+hddodi3exNeG5z1RPe2J1E4dyzhO6guuz7M5MpOjW 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 Tue 04-06-24 09:34:48, Byungchul Park wrote: > On Mon, Jun 03, 2024 at 06:01:05PM +0100, Matthew Wilcox wrote: > > On Mon, Jun 03, 2024 at 09:37:46AM -0700, Dave Hansen wrote: > > > Yeah, we'd need some equivalent of a PTE marker, but for the page cache. > > > Presumably some xa_value() that means a reader has to go do a > > > luf_flush() before going any farther. > > > > I can allocate one for that. We've got something like 1000 currently > > unused values which can't be mistaken for anything else. > > > > > That would actually have a chance at fixing two issues: One where a new > > > page cache insertion is attempted. The other where someone goes to look > > > in the page cache and takes some action _because_ it is empty (I think > > > NFS is doing some of this for file locks). > > > > > > LUF is also pretty fundamentally built on the idea that files can't > > > change without LUF being aware. That model seems to work decently for > > > normal old filesystems on normal old local block devices. I'm worried > > > about NFS, and I don't know how seriously folks take FUSE, but it > > > obviously can't work well for FUSE. > > > > I'm more concerned with: > > > > - page goes back to buddy > > - page is allocated to slab > > At this point, tlb flush needed will be performed in prep_new_page(). But that does mean that an unaware caller would get an additional overhead of the flushing, right? I think it would be just a matter of time before somebody can turn that into a side channel attack, not to mention unexpected latencies introduced. -- Michal Hocko SUSE Labs