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 0B9B0C25B76 for ; Tue, 11 Jun 2024 11:55:19 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6DAB56B009C; Tue, 11 Jun 2024 07:55:18 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 68A686B009D; Tue, 11 Jun 2024 07:55:18 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 503B86B009E; Tue, 11 Jun 2024 07:55:18 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 3113F6B009C for ; Tue, 11 Jun 2024 07:55:18 -0400 (EDT) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id E08041C0A1F for ; Tue, 11 Jun 2024 11:55:17 +0000 (UTC) X-FDA: 82218452274.23.F009D3E Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.223.130]) by imf13.hostedemail.com (Postfix) with ESMTP id C925A20010 for ; Tue, 11 Jun 2024 11:55:15 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=X3IdD+L9; dkim=pass header.d=suse.com header.s=susede1 header.b=Ctr3kmAL; spf=pass (imf13.hostedemail.com: domain of mhocko@suse.com designates 195.135.223.130 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=1718106916; a=rsa-sha256; cv=none; b=lRxHHKH3IqrXwqitsiSlFswXit4fNLSVgIFVtImYEbVl7Yf5st25s+0EyvdPjux99MEcm1 O8VGVRJ/ahaKvs6mp662SQKT0PH7MSbHyZtvPMHKhNUQgyNOQdjtSzw/bMRJwetW0AjzoG 4InVvrjHygUNHF2Q8bn9WWjDwMvG5IQ= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=X3IdD+L9; dkim=pass header.d=suse.com header.s=susede1 header.b=Ctr3kmAL; spf=pass (imf13.hostedemail.com: domain of mhocko@suse.com designates 195.135.223.130 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=1718106916; 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=8itFnZLoGjChMJJ6y4EBv6LeuFDHeLJfvExupX7tDis=; b=QoC+jr9UTv05A3lhIpiuFqxfMtsH01++glpndU+/VwZXb+qpHplehsDp+ZG+AZJDaNJq7h /EQ+YtgwQ6X9gLrTE73pZM9lFPRBZzx3Mg85b/7b78dL8kpEUiYuHdY+3Te4Y0lPSjmM3A XNaqAGCOm3Ayw4zNQtDmyOqo+4IP5kY= 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-out1.suse.de (Postfix) with ESMTPS id DCCBE3373A; Tue, 11 Jun 2024 11:55:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1718106914; 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=8itFnZLoGjChMJJ6y4EBv6LeuFDHeLJfvExupX7tDis=; b=X3IdD+L9Upk/xRzoYtKahqgAfQqEo37+NQCvJxidht45A0mGOCVOEjN1jx3Y3hyHdRG5CY n2oaYxRubnGNP5vou2a5PB1tEA6h5X2IMjwoB6kfRI5ivAVAo7hkpokBqcyi8BKRAMuexv lXFNATndfe2vPQepM1oc3k4D0CkPhoQ= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1718106913; 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=8itFnZLoGjChMJJ6y4EBv6LeuFDHeLJfvExupX7tDis=; b=Ctr3kmALNlU8j4/GHYTNIxsZa+1UHOr8WaPkI1vRV2bGtqnr2jcbk1LBfObKNqKj3WUUwe rN2yL+OG5ah1cj4a7FbhNgvxCB14Kx6QUz/0z++1d/w8JI5TgYEIMSRVQsNGV04orpNiJb AQWL22jlwXIO4rqGmcyx9OSvlQajfWs= 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 D17A213A55; Tue, 11 Jun 2024 11:55:13 +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 kDgcMyE7aGY9IQAAD6G6ig (envelope-from ); Tue, 11 Jun 2024 11:55:13 +0000 Date: Tue, 11 Jun 2024 13:55:05 +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> <20240611005523.GA4384@system.software.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240611005523.GA4384@system.software.com> X-Rspamd-Action: no action X-Stat-Signature: a5d6a6w8ks4p4t3fqc6e5cs598girm15 X-Rspamd-Queue-Id: C925A20010 X-Rspam-User: X-Rspamd-Server: rspam06 X-HE-Tag: 1718106915-924984 X-HE-Meta: U2FsdGVkX1/Ge4uha6cyk/y+a8P3ulvh16i19GFaG/CD8rDEg1IoWklVhIWFacICToBswBHZVSgOn6Ip7IL3eKfNpOVPgFtbsnX7NlLfP5nOY/W1rt3RFYIh7jcKCE1+pzn/4Djc9tBMdZtXrjnwBhXjz8VE1+K/kQ14v3h/T3sJugpbFSeeD/GLPTNc0e6xAAec30xaWsa9FE3H5Ej1ZKKTmgP+tk9rTwU+CEzITQ8PxeWVzb2ERh/CLVnvdWhyVb4gV+cmv24AWJPQ/5yxTFe3ojcakV7+R/fZyNf7p6BdaY20/eez4DDFXrboHrFBkvn1D79ptl+AqvIYpnzl/1g04yLVUmxWkwJfetmH3fHHxXn25xgjcMp4xvWrGcXbbe+nVH3W4QxOErjLWMrNACiQagMAEtp4ytrmId6Y5bbal7JaDmiDKG4XoHOJhgRtvYBa0KeGe4Q5Z7qid+7iQjMkQCLjh5lyDJVuqYH+MkJ1VU865gfjw2lyq31U7sNDkRSls8X+cNnNeSgrNvVdK8YjRmbvHrWjotmE6w1sZVeEvF3ct/e4ttPpy/+I3KqGYYeI72pye7Ik2NtMKyAXqEOT3yjEQ6uLZNaKmoDYhisAo93COIf2JjQQ8sbChQFi94X/1UTQverUurTfF3lMdlQqkuR1OEfnwgmtKgBackZH3G8KvEa3ZwZYbWTAenltJkTSOF9Mkj4evJLICLMksLp2KIuxw7ZWfdc7IUkDsISBEU4+umShKa5JcgdxoAzhhtX9fABRhJHeaeSGJP5+RzahNsxj8qzWcRL1G+lDbq8K5X6ScGCepJB1ivR52dVuI1Ig9HMUl4iyu9iWancf/arMf0kFQXysliMfcYs0h+Zh3cuiNzZPoCobdUeBo+16O+icPCLpujkL7Dla4+2wtpwIeoTwrRIlzjblEp2q9unfK1phinBD8hJwqtcBdYw9yDbJDvOPHfRucpeAOOh mj+QnlrD uxaLCEoLL9Vrv5Zwuk50CyWukviH0kdHfOEmnRY1qcE3MXlSKiZyp4FeK4X9c5YVFnjUcleCkSqkp78l6dTdA7MLXsShdXZ6BT+B+9XGkDGlWVVbn1SLVQoOnJTxUXCoz4UWotWb45djfGTcEnFPaWytfj4rqCa+qk0g5PRXz2M3dFi0nY8XmCaRHJyBTkH1dMYnM+AHr6Ohvj1fE7q6FBkkuZsZuDJtFs2DuN3OeLecH53mAeTt8jELqVXQxcX1lXWIQ+f18IAivPxEgJUI5z3zxQ2n0HZVuYyem 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 11-06-24 09:55:23, Byungchul Park wrote: > On Mon, Jun 10, 2024 at 03:23:49PM +0200, Michal Hocko wrote: > > 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 > > pcp for locality is already a better source of side channel attack. FYI, > tlb flush gets barely performed only if pending tlb flush exists. Right but rare and hard to predict latencies are much worse than consistent once. > > time before somebody can turn that into a side channel attack, not to > > mention unexpected latencies introduced. > > Nope. The pending tlb flush performed in prep_new_page() is the one > that would've done already with the vanilla kernel. It's not additional > tlb flushes but it's subset of all the skipped ones. But those skipped once could have happened in a completely different context (e.g. a different process or even a diffrent security domain), right? > It's worth noting all the existing mm reclaim mechaisms have already > introduced worse unexpected latencies. Right, but a reclaim, especially direct reclaim, are expected to be slow. It is much different to see spike latencies on system with a lot of memory. -- Michal Hocko SUSE Labs