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 0F5CAC25B75 for ; Sat, 1 Jun 2024 02:20:24 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7C4066B0098; Fri, 31 May 2024 22:20:23 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 74D106B009E; Fri, 31 May 2024 22:20:23 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5ED946B00A1; Fri, 31 May 2024 22:20:23 -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 403836B0098 for ; Fri, 31 May 2024 22:20:23 -0400 (EDT) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id EB3FE1C18EE for ; Sat, 1 Jun 2024 02:20:22 +0000 (UTC) X-FDA: 82180715484.28.45AB3A2 Received: from mail-yb1-f169.google.com (mail-yb1-f169.google.com [209.85.219.169]) by imf13.hostedemail.com (Postfix) with ESMTP id 4632920004 for ; Sat, 1 Jun 2024 02:20:21 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=B6pF4pTJ; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf13.hostedemail.com: domain of lkml.byungchul.park@gmail.com designates 209.85.219.169 as permitted sender) smtp.mailfrom=lkml.byungchul.park@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1717208421; 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=29hoWkRwJJopRTaD5yxwEHHavNk9SWern4C/CoRhJEA=; b=66yiTvmdqXySipjYtQ7pYxNrWR4lOdFbdEkbazEkQp6tnKl1iLrYyvus1wJ7LOtFghih7h iL3JCmqqleCAhd3gf2ym2fP0GEDuSXFeYruCx82TzayOag25VmHIDnnfthO+mfSQ+2pgw1 QzJedAKr3/Jb8QXWNeuG1iwDJZz8uUs= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=B6pF4pTJ; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf13.hostedemail.com: domain of lkml.byungchul.park@gmail.com designates 209.85.219.169 as permitted sender) smtp.mailfrom=lkml.byungchul.park@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1717208421; a=rsa-sha256; cv=none; b=oEHXsPJMXSTFfph/l8ANF/LgftV1D5nmKIiyjxsJHveai+xwBYkjGtJ88KwBTmk4S8xImR 5/uImsWyHZnLN3ULf6j1KdS2Cf5C4sI4sZAcCaESn2R3Es0uDoBhb3rdlfa3du0XQRYiy8 +hKVCqOxEslaTXuewBphQ5agAEqH/2w= Received: by mail-yb1-f169.google.com with SMTP id 3f1490d57ef6-df771b6cc9cso2581259276.3 for ; Fri, 31 May 2024 19:20:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1717208420; x=1717813220; darn=kvack.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=29hoWkRwJJopRTaD5yxwEHHavNk9SWern4C/CoRhJEA=; b=B6pF4pTJPHlx+WygG/SK2PP3vm5Z0v4wB0dOHor+Wf7EbI54FJgQIqT80AGO8npGu7 HvfPSufP7OA196A6T0aYO/dxcLjCcqrWln8HMZS5/wuSzMa+IrQ6N6Jok/gXn5qtaDv4 RVhxIWves6yVEkQmzWanV+D7WwD2hHIC7IMpOErozLoYoLbJ+/8TOl93fkqrXkgrNLlz lhfrgTxy31sWqMxaCCy8gxw0BRdCmvwA86sgSjlyJ/q/6ykNIbZBZK0yUEXHP4x7XWo9 RJdXETIR5IOoKN9avG8maDTZNsX1FwtTyDkdqYdECVmEkUlKzwBZxDMJuBdeutlB28Y9 vj3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1717208420; x=1717813220; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=29hoWkRwJJopRTaD5yxwEHHavNk9SWern4C/CoRhJEA=; b=SMcPAXXQuUMN9AxI1sDAwxlrqEfW5RvSlqalMcj2xzMuINFwVeYsgn9uojRXvSjGPh cur2q6n/7sE+EQ3cBjdSZh9zF6jbNR733VBFdZ9hsF0ewxmitzbiEnUIrNIHlHn4ZNHe D8DPgcGTH9FyEMUWFHYSISrar+3bpGWm6vRF6bTao+nKFa4cjhKzIHFyMKXlJPBLEXE3 7zCe9JJkKZB0R3SCVZCBItEZwFrw2gGW/4FvQyff3zdIn/YuUU0gR9e9XT4jLR9BjH0Q PfTTCCtqRlY9b5S19YiteHwqLCl8xLzfObGCaIMeW7lN2gLwX2vKi3gaGQdAeL4odTwx 8+KQ== X-Forwarded-Encrypted: i=1; AJvYcCWo45aNjDs09N9vFTOegkhPWTJrsdg+j5tkpMrCCQrDnSdPNdsVklGy1rR2BR9A9UMtnv20qAlkS3fy2jAflVRu3VM= X-Gm-Message-State: AOJu0YxcQTpwIJxYKLOIiq6OslgmF7NpCMgJtVrAh7WTNkMo93oC6Sl5 qIvJUH0qjCncItQDxSE77KtwaxZCy8tEqS+KhIte9BXuC4IbXYU7vSxnl9KawzawSk3C2VfcJPd sWOf6D4V6IXumU8Xj4M0C++Tb9mg= X-Google-Smtp-Source: AGHT+IGy6bCFfl1yWZRJ07bao/Kf4yf50om6Rq/dNHAF0qvBIOgq20a3ir4uuahipLj9SFZjwUDi1umBu4WFLZDCRlQ= X-Received: by 2002:a25:2fd7:0:b0:dfa:7513:59d7 with SMTP id 3f1490d57ef6-dfa75135b5bmr3509883276.65.1717208420279; Fri, 31 May 2024 19:20:20 -0700 (PDT) MIME-Version: 1.0 References: <20240531092001.30428-1-byungchul@sk.com> <20240531092001.30428-10-byungchul@sk.com> In-Reply-To: From: Byungchul Park Date: Sat, 1 Jun 2024 11:20:08 +0900 Message-ID: Subject: Re: [PATCH v11 09/12] mm: implement LUF(Lazy Unmap Flush) defering tlb flush when folios get unmapped To: Dave Hansen Cc: 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, 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 Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4632920004 X-Stat-Signature: a73onmyqixycde4p4cj6hxbzc636mxbp X-Rspam-User: X-Rspamd-Server: rspam11 X-HE-Tag: 1717208421-112030 X-HE-Meta: U2FsdGVkX1/I0SmUCAJrfwqYxy4Q18QGYVqfufpOimIaT8s+Ji2tr4zxAOIEmnEMgwfMXXGZa+rm7KxSnx6xXEFwZcjdsHKTC9q6Z+f5hJens2QoJa4oMBZZ99wFyKAyZ9EJ585kdyXAzNc03pSyiLD5sfZL0PxEGDiwWey5n3RgUuM0V4X3ct6rINnzZ30T3KNvrXq8sSUrrteRQGYIHmDrHEZYTo7cg/myuHDDlBJ5rXiImRTh65Z8ShQWz9zGUwH+ebglOb7bmo2UKx+wSh9PneQg6a5H4uWjLmACGcvzR0t5jUCz2K2MfvhrjqCcVOwyl1mhR3A++aYvCLvQoZeW45jROWct4Xi7pLB3UOJfP9HOzaLscaIGy78MWq6+lvKv7wV50YUrTIz6kOHF5tlAIdTzcmkC2riBSxix4iVqamJQcghjkcRQf7y7gNcohneocxF16Qiegl5bwj+xGCjU78MZN196xd+6IzBUOxCApJbtvpFk5ANzfCn32lm55ZNoNRgxxqaNYR3s4YrIUup9AGgLwPxVjjnDVtd2tKvbLBnrhO2p8yYA6w1ZLqpOv2/mY0/b8Z2jB/GXg9GiFnzx+vZlsyXEvjGJD/EcunwDwOIVdueDB7dAolqyNH7bdtG0teiPnlgFjj6GieG/U/niEj4jmC1YM6WBvhMwz3HSOyvvx91ehE+dk/MhBiJgxML8+OFkHHz6gdMC/CZjE+8BCjGOEfUrREPWuLDNFNaUFhV+yaxkzP2QaQwsfcsG8xIpb+WHt1f6T9pAXBx69pjBAeskJeVLHZD+XwVO3ERCR1axmVkbh4cnm7df5redURLq0gsgWHMY6FO71xwT2vKF0kvvJM0JqFlNfp/kYSU192ESxc6PWMceQH9kUIdlbj5A+GNUE46x/8FcJ7raQPHuV0A0Pks9ljTB1XfTlv50MFIC5zDTmuXDAZG93uqUdxbjQO4Hs+AQ/a6WKLw bTD06/EY G4TI7SNcemxFmnb11/V2i9QwFMAUGDT51FddeQjgL19vSc8vuoMvxrxWYvlqCkznb05C3IXnju1GQoNnvCtiB3mN75BVV+njtrfmT6+YPizLnBVHyDk3/Yly+pOoANlmWdL9qUlvgwnXvNoBsQ/oDrU8bf1DOdtK8Mg+mW+8nmYi54r11OyRPFRk+PWe3fx+YspOI1XgKFp41zqeG1PaInRXhtDEQ9BmVwVnr+VwCYLCMHfgs4PNJpMpRjpgrYogTZJfOZ3r0TtxbIiS1PwtWgxEu0GkaROCgTqsfqbnssOJ/Hwta+EKlA1KYXPsEoCo7KnO6 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000003, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: 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 All the complexity comes from the fact that I can't use a new space in struct page - that can make the design even lockless. I agree that keeping things simple is the best but I don't think all the existing fields in struct page are the result of trying to make things simple that you love. Some of them are more complicated. I'd like to find a better way together instead of yelling "it's unworthy cuz it's too complicated and there's too little space in mm world to accommodate new things". However, for the issues already discussed, I will think about it more before the next spin. Byungchul > 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. >