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 0FB2FC27C4F for ; Tue, 11 Jun 2024 00:55:35 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3AE586B00A2; Mon, 10 Jun 2024 20:55:35 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 35E1C6B00A3; Mon, 10 Jun 2024 20:55:35 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 226016B00A4; Mon, 10 Jun 2024 20:55:35 -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 F38F06B00A2 for ; Mon, 10 Jun 2024 20:55:34 -0400 (EDT) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id A62E7A232B for ; Tue, 11 Jun 2024 00:55:34 +0000 (UTC) X-FDA: 82216789788.22.B960B30 Received: from invmail4.hynix.com (exvmail4.hynix.com [166.125.252.92]) by imf16.hostedemail.com (Postfix) with ESMTP id 130A3180003 for ; Tue, 11 Jun 2024 00:55:31 +0000 (UTC) Authentication-Results: imf16.hostedemail.com; dkim=none; spf=pass (imf16.hostedemail.com: domain of byungchul@sk.com designates 166.125.252.92 as permitted sender) smtp.mailfrom=byungchul@sk.com; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1718067333; 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; bh=RSmsI6OS/o1c+x+yAM88UzoDhpV6UQmOqV7gZI0xHTA=; b=mpx/v/vMK/zAThfjZkLxmBANJCeK2Anqdd57rX68SVovPP4aS84IGgiBJjuAlRArEf/NxX uiqANjJG04BlpKNwgfXi30azl/QmnT1Mel06rgl5TwZKdCgG0ab4diKUNFGuBQBUJUYC6f IghVsHgbvT6JFDbrUQDm9ky6dWlg/0A= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1718067333; a=rsa-sha256; cv=none; b=rp+VhYLYiAg3kCala1gN7LhScQwl1qjc3WPtzg0Ii8PvnqgYWf2xl5Iv7BlGzCw4goovqq bXxxfytE7p1ZeMlw20SI652Fyh2/bWXQDjTnDfnExLNF+mDb8bwzjweL/Y14CWPxEOcBDt ncJ2rbxj2u2hh+kmeq8pFIDHgeKGKeA= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=none; spf=pass (imf16.hostedemail.com: domain of byungchul@sk.com designates 166.125.252.92 as permitted sender) smtp.mailfrom=byungchul@sk.com; dmarc=none X-AuditID: a67dfc5b-d6dff70000001748-3f-6667a0816763 Date: Tue, 11 Jun 2024 09:55:23 +0900 From: Byungchul Park To: Michal Hocko 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: <20240611005523.GA4384@system.software.com> 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: User-Agent: Mutt/1.9.4 (2018-02-28) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrPIsWRmVeSWpSXmKPExsXC9ZZnkW7jgvQ0gytrRS3mrF/DZvF5wz82 i08vHzBavNjQzmjxdf0vZounn/pYLC7vmsNmcW/Nf1aLo52bmC3O71rLarFj6T4mi/t9DhaX Dixgsjjee4DJYv69z2wWmzdNZbY4PmUqo8XvH0BdJ2dNZnEQ9vje2sfisXPWXXaPBZtKPTav 0PJYvOclk8emVZ1sHps+TWL3eHfuHLvHiRm/WTzmnQz0eL/vKpvH+i1XWTy2/rLzaJx6jc3j 8ya5AP4oLpuU1JzMstQifbsErow1P9cxFhwRrNjU3MLawHiQt4uRk0NCwETiz/7HTDD2j8Nn gGwODhYBVYkr7eIgYTYBdYkbN34yg9giAkoSXZt3snUxcnEwC/xnlvgx7xgbSEJYoEDi1YRJ 7CA2r4C5xMwNT9lBioQEfjBL/DlzhxEiIShxcuYTFhCbWUBL4sa/l2DLmAWkJZb/4wAxOQU0 Jbqe1INUiAooSxzYdpwJZIyEwDl2iYa3q6DulJQ4uOIGywRGgVlIps5CMnUWwtQFjMyrGIUy 88pyEzNzTPQyKvMyK/SS83M3MQKjdVntn+gdjJ8uBB9iFOBgVOLhPfExLU2INbGsuDL3EKME B7OSCO+ZmPQ0Id6UxMqq1KL8+KLSnNTiQ4zSHCxK4rxG38pThATSE0tSs1NTC1KLYLJMHJxS DYwOOyZz7//i8jvcxmgK/wyfs8nS/bvlz6//MlvLyeSqFUPyCQNpdr9bemU6913Xt4rfVDl4 7NC+67t51M4u3nn4UvxEq3AZvzMxdZn+bO1b5p2O2rjh0KveDN51nr+YNPuLDy37vqNW6oWJ bH9AXg2LCEeucNPvto2Ksronlr+ODY7eZcCz01yJpTgj0VCLuag4EQDau6sG0gIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrGIsWRmVeSWpSXmKPExsXC5WfdrNu4ID3N4NwVVos569ewWXze8I/N 4tPLB4wWLza0M1p8Xf+L2eLppz4Wi8NzT7JaXN41h83i3pr/rBZHOzcxW5zftZbVYsfSfUwW 9/scLC4dWMBkcbz3AJPF/Huf2Sw2b5rKbHF8ylRGi98/gLpOzprM4iDi8b21j8Vj56y77B4L NpV6bF6h5bF4z0smj02rOtk8Nn2axO7x7tw5do8TM36zeMw7Gejxft9VNo/FLz4weazfcpXF Y+svO4/GqdfYPD5vkgsQiOKySUnNySxLLdK3S+DKWPNzHWPBEcGKTc0trA2MB3m7GDk5JARM JH4cPsPUxcjBwSKgKnGlXRwkzCagLnHjxk9mEFtEQEmia/NOti5GLg5mgf/MEj/mHWMDSQgL FEi8mjCJHcTmFTCXmLnhKTtIkZDAD2aJP2fuMEIkBCVOznzCAmIzC2hJ3Pj3EmwZs4C0xPJ/ HCAmp4CmRNeTepAKUQFliQPbjjNNYOSdhaR5FpLmWQjNCxiZVzGKZOaV5SZm5pjqFWdnVOZl Vugl5+duYgTG3rLaPxN3MH657H6IUYCDUYmH98THtDQh1sSy4srcQ4wSHMxKIrxnYtLThHhT EiurUovy44tKc1KLDzFKc7AoifN6hacmCAmkJ5akZqemFqQWwWSZODilGhg7KlXuf3J6L5x2 TVVA9YHfacl3xg7GKf76T0TzzdOW2feydeyRPZpT91xH2Znz+yMlkc3z/XzXxT/00fn2+irH 4ftrlr7+eXIlS++7wG3X93K4Pj9/wPJuyfzgun+TkmNN/m1uYjq//eMfY4+jh82m3BaPMjX5 dLrNi+X8E86k7yy+TyPmy8xXYinOSDTUYi4qTgQAvvh5wrkCAAA= X-CFilter-Loop: Reflected X-Rspamd-Server: rspam03 X-Stat-Signature: szfh8fhgxwhfq61k6ote5qxpafgw8r14 X-Rspamd-Queue-Id: 130A3180003 X-Rspam-User: X-HE-Tag: 1718067331-477880 X-HE-Meta: U2FsdGVkX1/Gdlm0r0bMWmCDihitsgpVf0FEESTqi9fM3LvGKe+lfmCTfw66QvuI6pnBKQ2A54sUhk5RvS9y+yEgvL07l+WkL8ZlHZmWjXdaDXjmkos8hSkY/EQtPBcKK5O+09RG5v7zrFT30elYs5FcjDJX+iQR9imXnb3da7EaXk4QAW1wjKeZru36B2wLcOnrTRI8X6aNxcHhn7Ept80z64zay7hZUptYEUrSk3sY9fBrZ6D7rmmNLeagtamfmSkHJVn9IRvq5On07BoPUCWmFAXPxi73P1n7FGLHtLIgN12Uc/TkIFA9wnyVVb2FkcYHskfjmiXLRy4pw/RuX0PJOlx/LsFAeRJGjdo7X2rtUdlyjENzIyk3EvrhBEZ6kUgVBU0Q7ILxWxGtJUv8IUn9ggMZiNbs7HoywkDP3bB0fzbLLs5uxTndzL4AmcULenlepsw64yAWCmtHwFADyf/T/GhoFL0uy7sML4GAbzAsNRvamTaex44mNJyeq8hIy2sWho1Tb54cK967B2K0seKAKkhidPe9K2J63KA+TSHMoW3re+GchPHm75F2n1GOIGkQIKNDf/1S7kLMULtNV4AzJfup+qaCRdKGC3WTO8O4EDiHtwwmTXnHuCfi56jD5Sv3G18XqPAZzgUaWnPtD6nXjmP5l5WXo9yLAC/ipatV1+/XQ5g+KADJgvs2pwVz1wNEVySUnNCjqGhEwUMJRDXvF/PJc5IeUt89mzvHISSFYfaql+0YHIgA1L6WzVuA0bU9koD/rkER0ZUTvaKOLuORX0Xft5Wxyqbz49nlibTzO+FDEK+sLMjlbrry4o9OqA4KCsbjZFNVf24Ti5yN9FvMzmSWjfmPP0gaT4OlWIc/VjKd8h8kdaw4mY6f9fXV8U9dSO3imQfZ1oHazhCjothXQMP8uKIN4pOBlz8GDgDqsEpz3GB4q8EL3vuR2RLDDZsAM5fTG2n9BCgMmeF dldW95h/ pbsPyms4PQHXfCdU= 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 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. > 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. It's worth noting all the existing mm reclaim mechaisms have already introduced worse unexpected latencies. Byungchul > -- > Michal Hocko > SUSE Labs