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 26311C83F03 for ; Thu, 3 Jul 2025 17:34:39 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 704A26B0260; Thu, 3 Jul 2025 13:34:38 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6B5346B0261; Thu, 3 Jul 2025 13:34:38 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5F2636B0266; Thu, 3 Jul 2025 13:34:38 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 4B5F46B0260 for ; Thu, 3 Jul 2025 13:34:38 -0400 (EDT) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 08848588FD for ; Thu, 3 Jul 2025 17:34:38 +0000 (UTC) X-FDA: 83623653036.17.0A14CB2 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf29.hostedemail.com (Postfix) with ESMTP id 5A99012000F for ; Thu, 3 Jul 2025 17:34:35 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=FPzHa813 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1751564076; 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=OWB1t5fsA1yteyotlpnQA7pAyDo5DDfi98K8/8ko/0w=; b=JzoHis2Ndukuv33Jeok8Wxqs3jUnNGEF57BWpH2rEsolloEI7/bc+bza50x8B1mDfEac/c oghcKl7lW6CAP2vTWQEGW+L5wyq71BPVsoPuU9teRAR1mVkZ86aXJlXivp26KLFsiRuQ7w +GETPTWo+cDG64zzElq+mfi0umC6LbM= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1751564076; a=rsa-sha256; cv=none; b=47FJ2/AmcD6O++w3BmI9cxPIxckIeJYaDIPP8Y7IIZMzVHbujai8qlxLxk3dkCMIAMEUtY joL9bB3VqgucyjOo94BEi/lCxomGm2tYl5DQKMhyhIPBKkmDDDy4Zkx2hBOeOAMsE/pyxC RMbXpID9g0s1fMMeCccuFHIQSRsPmHY= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=FPzHa813; spf=none (imf29.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=OWB1t5fsA1yteyotlpnQA7pAyDo5DDfi98K8/8ko/0w=; b=FPzHa813kryaam2+V7sRBYnun/ y/egD8SelkoS0Nt7ZCPIt4bOotNndyMv/qlv2AOw6jG03lKOVurJkvycQbZl4KLgy63na1tBft+RM hhFAHH8dsRXzCrxiFb6k57gkTwpXPnIpwLrAVr5H6i+BjMm9xuDitLTM2Rz4uhW6PJFdgTs1H9ru+ T3ah/X7EJaBaptqpAQgf6HWXzQopYJFt33PVAMp9183A+EkLf9wQhnS4zupnxROY8+/dS06JOOAoX zYYtfP/tEL6zei7usyZPy9g755PwxDZzncMopeiH5YRJnBt1Jrrvne9Am1Oi/mDxOGjUmYu8IKuTB NNsRtefg==; Received: from willy by casper.infradead.org with local (Exim 4.98.2 #2 (Red Hat Linux)) id 1uXNpE-0000000DsHI-3pNd; Thu, 03 Jul 2025 17:34:20 +0000 Date: Thu, 3 Jul 2025 18:34:20 +0100 From: Matthew Wilcox To: Christoph Hellwig Cc: alexjlzheng@gmail.com, brauner@kernel.org, djwong@kernel.org, linux-xfs@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, Jinliang Zheng , linux-mm@kvack.org Subject: Re: [PATCH] iomap: avoid unnecessary ifs_set_range_uptodate() with locks Message-ID: References: <20250701144847.12752-1-alexjlzheng@tencent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 5A99012000F X-Stat-Signature: beese1zwe7nc85rcmjuaeqn6y1reqxdt X-Rspam-User: X-HE-Tag: 1751564075-466330 X-HE-Meta: U2FsdGVkX19C0yX8HwCjyXHVFwbVliuuKN9E8XnWSHozm+rCUcEqNlr/i8txCpHIROxCG7qLTdg2Wu6qazVLjjAzLOafu6Oefg6epqMqwpAsZNC76twj4DwwdGyZNHJhL+n1CKKykCrlaXOPEDDh+MpY6gQreH66154LCVr/C9uQmnLcc9nG7VnVNRHe+DEjYaB0WselpoOr1TpjRI1DWNM3y7IWsXWuZ9pKK/ur9Q6rvlpJR4Jm1I8aOanO7xhVnjq+X1T1SWF1SFfTf523GCDgcugzKVTTIFdTKhJHUrDTflU64gTA78sMEti2kvOc1qrAttRO+6xqxYnZ/fcw3CxNpQnOqN1BY1mEhyE1bJ21rDHTee9tnJXX73gzXOxSxMe6lTCdnwjh4Qs/vqoJZhhfJKX9ubafqlGxOdNSYXFxMmuJaMQ41XVXruMJWENxtU/wJLw4T0W2BJU/g1qpo/hR60aY3hFsCEHJUDnCRY4rHihicooaNOM7mhhsvcv3E8jN4b6kvIKrP09ygV8vB8WZiUyxCPHY0fUM8PZ0ligU/pXByrjVY+dpX4E3rsB294V9u3r8jtFE3WzMJ93caZ1sS0w6r60wqOs2tQV20CvL0pZYEb1mq/ttqAfYrPE0Q8xPRnbLVhpUYm/8+cG0r33JO+nHVAzzimc14O7rWGB6SgiuJUgtM4QYUYglg/yyk8X6EQ/CeRxgZ5hLIzA6BkDHIWZpuX5kEXdbUxFwhfnXnetx2aW3EVOTOjyFLocmnR1KHEgntsl7Bz8LOxNo5FpfEnLC6D2ZDNqxsJFsb0gxc5CQelyNyxgHCVZyujpa6SQav1cmiNnTu/dwad4Lqt2XTvfHfSaxwAWvsxWopjlNzDb/cIyIYt4nqwKG8DnX83HFAvlv66+CCLCbJQjUlI6DZTyHmbiPt9vQWbqLht8qO6yx5xbzDuJOcE3AqoobKMKbNnAQkbrCpBK7tuF Xj0VKgQH IFzx2nfFjijhxmqcYGJSauR97dAaRiFnZ6s6BDxQD+MVQDctKyaiYOjluwrUiQCu4rAlR0BIVkAoVSXD+dxDVFyMqtb74pVQ6RG2BUikfpSHl/f2TfJ+ElxVlEhYZ8ch3M8LpOHxrH1t6uj+RPcnaIwdRFOPDLtY3GKLaRYsxoyAHmnUdyoC0oZh9wcX0nrphcqaxHAniAGb4qvafh5/vlXr4JVcowxQ2cALTq5nU+bmkTN3u73DRbvK7DJ8AaRActFNNz5EuRGaBxgdZErsUeqzitdg91LoIzpu/FDr5nfs1Jt2DNfg9DoM3zg== 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 Thu, Jul 03, 2025 at 06:52:44AM -0700, Christoph Hellwig wrote: > On Tue, Jul 01, 2025 at 10:48:47PM +0800, alexjlzheng@gmail.com wrote: > > From: Jinliang Zheng > > > > In the buffer write path, iomap_set_range_uptodate() is called every > > time iomap_end_write() is called. But if folio_test_uptodate() holds, we > > know that all blocks in this folio are already in the uptodate state, so > > there is no need to go deep into the critical section of state_lock to > > execute bitmap_set(). > > > > Although state_lock may not have significant lock contention due to > > folio lock, this patch at least reduces the number of instructions. > > That means the uptodate bitmap is stale in that case. That would > only matter if we could clear the folio uptodate bit and still > expect the page content to survive. Which sounds dubious and I could > not find anything relevant grepping the tree, but I'm adding the > linux-mm list just in case. Once a folio is uptodate, there is no route back to !uptodate without going through the removal of the folio from the page cache. The read() path relies on this for example; once it has a refcount on the folio, and has checked the uptodate bit, it will copy the contents to userspace.