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 17C77C83F09 for ; Wed, 9 Jul 2025 03:30:49 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A67AD8D000E; Tue, 8 Jul 2025 23:30:48 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A186C8D0001; Tue, 8 Jul 2025 23:30:48 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8E0358D000E; Tue, 8 Jul 2025 23:30:48 -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 775E18D0001 for ; Tue, 8 Jul 2025 23:30:48 -0400 (EDT) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id F0309585FC for ; Wed, 9 Jul 2025 03:30:47 +0000 (UTC) X-FDA: 83643299334.30.790FA16 Received: from mail-pl1-f170.google.com (mail-pl1-f170.google.com [209.85.214.170]) by imf22.hostedemail.com (Postfix) with ESMTP id 1A62AC000E for ; Wed, 9 Jul 2025 03:30:45 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=kSBknzjH; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf22.hostedemail.com: domain of alexjlzheng@gmail.com designates 209.85.214.170 as permitted sender) smtp.mailfrom=alexjlzheng@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1752031846; 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-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=8mu6qUOHQ62RBIp+xk62nasWAenaXUSglvP48pK3Jf0=; b=IV30EjaiL/myedmwpqkU8ewUVMJW2UhV6L9CSF5oILWaUgX7+cAaE0X5LS2y/3fAA2u+Gi gOJwwYkCoZPhVVH+L/gzGqj0B0I7OmxkSs5pNY9rDRD0/rTMQjI6Mu5lgU+0vko5nNjMwm 4L/3Eq10Z+Kq0Q9WuwhV8CL59f0M/qU= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1752031846; a=rsa-sha256; cv=none; b=xovSzpWr8kipCeJ45T8AIGv7XdynAOA+2lcuZlp35c25EwogWAPNzeaJcaHKURdprMmXi9 DZSuNUh2BUtyud9u1JfH1mUuEYjtTPFbDy3emuwdURrmQQlJUXYjZKRm7U7XcXxbVvGghV svmvyStGMNQacz+fXrOe0Ndf9jqjLr8= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=kSBknzjH; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf22.hostedemail.com: domain of alexjlzheng@gmail.com designates 209.85.214.170 as permitted sender) smtp.mailfrom=alexjlzheng@gmail.com Received: by mail-pl1-f170.google.com with SMTP id d9443c01a7336-234bfe37cccso59440075ad.0 for ; Tue, 08 Jul 2025 20:30:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1752031845; x=1752636645; darn=kvack.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=8mu6qUOHQ62RBIp+xk62nasWAenaXUSglvP48pK3Jf0=; b=kSBknzjHlj4b6qBvkqo2pH2B32elzMSQHuXP1T2Fi6rX6R+675+62Ic6md71XfDEZC YwS5wZ8Wb3WqTUw0sVfU61pIwtJhyX/NEvwq9aQShcptJYOPB5Ot1+UO+5+mBUyfmgdL Kz/5xe4OsbcFs+QA5jqaKu9CRaDhDaGFFSfrDD5sTcYVOIDupanfcVjlzbKH2tZrk8eQ 0QzLZhFf6h24vxvbQ7/JYzgUREOAAipsEcO7g4NdgfeJ45N3OTL+53KaaSMJVWsq+t7F 15qsDMTlR0yrYfO+K76BQ/VDARwd84o0/7phK2ZlsosVombIJnrQnXqbBsXR1xVae38m aGgA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1752031845; x=1752636645; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=8mu6qUOHQ62RBIp+xk62nasWAenaXUSglvP48pK3Jf0=; b=fe1WTpCcS56HmM1NM1qGFP+4EJ/LQdPbqKW2ZNe5P/Ol7hnyjdKrpqShpwwtQpJFgu cNr9jI7kf2JZfzV+1q8cger6kIPyiqfdSPPZ+Ax4yFC7QxH5yR7qUpWzWWc3DKMLGFZh CZyKYkY3u7HueRfMvKSq+8jfLiMV8ZVgRAkt6w0oXdBHA5lqyTF2VjMT44liK79lv4rN 8hNJI9Xbo8+nW9lHTyQRGcuWnzzcy8vIwuTATF7DUPjL6Si7CymmEZ8Umcg1Gf6JLaL5 FqQKFIM6Ap+Lf/FTYp4gZpN/VraKZ0aCxplepyV6ePGeG2gSZ2BrWOKQE3nmGMq/BEDe tsRw== X-Forwarded-Encrypted: i=1; AJvYcCU4IRjaigYB22YLfVsZtkra1UEmps+5G9m0azoYLewtltbX4fmvIpnfThwzU6sjcv2fPlgcDh0ljQ==@kvack.org X-Gm-Message-State: AOJu0YxnYFtHFiCQdGfAcceG+lAYfQeRXzpw2wHI6Vto/k/hJJCQq7Mq jYVmR3kYg5qUmh4dnTfSk2G5aIb4e3QsOJp2GkUCCPw9R7LCSjR3MYju X-Gm-Gg: ASbGncsT4IZfP7dAZu1uI7fYnGNce0P5+MiK9KHXxIBYtm4RcGklHQfqM0CrrfX7C/A /lgpqhu68nuaJ/tzsL/CaheN4WC8tJZnm7ilw0CYZzIQ0SHpc38QG0n3QuEtdi0MwfJR3w3xxjf lPCi3pRtJnl9O3Xor0i1R4oJl9RreLjjSEOVC4ztCVprDsc9KdjNdFSdXNx/Ny9JUonXxBoduSv 8FUC2vIVaeHyosJoSR+aYBDKs7p3ZsXjAgOmDREFHc9O32b19HaFgl131CUvPr3p5GMaf3MMmva inZruIJOg2P61yVprRlVmN1/MEyqPbkpo/WJ5N3FOTk+vZzQpWqtmxr51duxxogWnkAmucP/tcc = X-Google-Smtp-Source: AGHT+IG7aZWTUwn23SxMC3eQ/hg09TylcFKw+KpHm/fuTh5OjVZqgq1jP2PLgDc/JKXSil+HGnCm7A== X-Received: by 2002:a17:903:2a85:b0:235:2e0:aa9 with SMTP id d9443c01a7336-23ddb1a6e5bmr17280675ad.14.1752031844730; Tue, 08 Jul 2025 20:30:44 -0700 (PDT) Received: from VM-16-24-fedora.. ([43.153.32.141]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-31c3017ca59sm666369a91.27.2025.07.08.20.30.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 08 Jul 2025 20:30:44 -0700 (PDT) From: Jinliang Zheng X-Google-Original-From: Jinliang Zheng To: hch@infradead.org Cc: alexjlzheng@gmail.com, alexjlzheng@tencent.com, brauner@kernel.org, djwong@kernel.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-xfs@vger.kernel.org Subject: Re: [PATCH] iomap: avoid unnecessary ifs_set_range_uptodate() with locks Date: Wed, 9 Jul 2025 11:30:42 +0800 Message-ID: <20250709033042.249954-1-alexjlzheng@tencent.com> X-Mailer: git-send-email 2.49.0 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 1A62AC000E X-Stat-Signature: jkp54wmkx31ydozfphdytx9cseknbasq X-Rspam-User: X-Rspamd-Server: rspam06 X-HE-Tag: 1752031845-940847 X-HE-Meta: U2FsdGVkX1923vU6OX1UJCtcl6b4bzuZZysJtvGECTBJupwDsDMiu9GUurKtd1/YXX/ZpbyxVSgIF+sIeLYbWrXYdqmm/R3kDI+3OqwltCD2DLMCQ3MGrAV22ig/eKM364jqsac1TXnAMH9WvurvSk6umAEZ9dZ90GDfp9eNqtzIeGX1LezdimCyElVWAZrvrKDs2oGuHWGakloEbcRFZP+XOMHP2ZiWxml9f4M2rtiVd/Qrf/PdHM+VCGxOX+HW+DFDh/WRVoXXmiyVQxsfVqlrTnVUcdkPt9gciAKSZ4GMXk4ms1ZhPTybuZi7jG8EHxGCilLQIWE994lMwLcv3Aj1QWBjW3cwgIZTYXSaREw4bxdshyk9U/QYWC43fJpcONscC+ctfwT0u+6iyv9a3/lTJIaopovJFcUtODjblv/fFxrLD49OpuAJIQWLzLuDgMH6H5y/EpyuPZPQ14VTvKdfZmhOU5o4hLG25xg1XHnLKJsU2Gx+pJCVFv1UXmlhMOV/jkXxlc0HRRfZvtshjd0NCMSMIMQibalIUaY8w6t+VBBTMjgltFeEStJChxHvJMAOj2phNorbncQNJCAvWwQ4DT/4Oahc8P998EiFIt01nhaVKkuuaxc2YEqYdCHpp1SoRIVamh0Y3viBCqGP/5qkJxRNCu137nRh9d/dRmmJPiZGnpw1EzZTx7gKtksbSlKW2vuqIiqsOSCf0g2nGsFL7rN3XVZKOaBBp2IdhqeoqQXqwv8IpP3t+Lvl8yBfZPbnQCH1eYYZ2lUvNQLrbsGN+NX7BDSHOAQ4lPZn3FgVXNKhUuiinKPZQ8bqUCGX22zIN7r0TGjNyddP+tdKvCyrIeN9cVSxEH3CHCXJwBV1QFp5oW+9j0QSRtw/3xUzaWofs9oS3JUlVmPFv0fNZ/5MFAs+etKeSyjKQUTYFiuex0CXjVJA+v94v1aSssoYayf7qRndfwPR2OpB/id RudyHX/1 J8Pmp0ZbkbLjcbh8KOuXpgCPCLFoVt/jCbkwKVDOERzR2zRuzO9Bv5JJziNeeiMlpbNhXaN3GiyVO6Ay4D2bmm/E6mTx6rtjd4hDu04Y7xrOSxtt/hfzWimAd3nhAVa441XOwGycYdaYmdOnbEyrZEDU73lDEj8ZLnmqLyJl9Sd+jI7brjH2D/R/eCkXtdU4bs2MqfalB/tZ66hQPEyzOCyVkBo+ot+0K9/qlB85xj8PR7YTnQk7kY5OB8umM8NnSOSbDcjimRb27DmE0b+gNWq+L9pCigpr/tOYC2f4mZ0wTx6ZdE5NNz726vEJFJoJe1BeOCtgNbVWygJr/nyoAZEVHi1wvVCG5dW5PGWSm50OO6k0UKgKgRSoEKWzawqieguRTplFAI09ZCPgTexUjghLTuyS80ayV5cODUrdAP8UNkWcgCB9mL5EEN0O3c8L9WJR0jBlB4tuZiwnk/rpeYwxzX+msynigD/Z2B1kJgDLRs9W9PDyiI+3D0w== 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, 3 Jul 2025 06:52:44 -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 Hi, after days of silence, I re-read this email thread to make sure I didn't miss something important. I realized that maybe we are not aligned and I didn't understand your sentence above. Would you mind explaining your meaning in more detail? In addition, what I want to say is that once folio_test_uptodate() is true, all bits in ifs->state are in the uptodate state. So there is no need to acquire the lock and set it again. This repeated setting happens in __iomap_write_end(). thanks, Jinliang Zheng. :) > 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. > > > > > Signed-off-by: Jinliang Zheng > > --- > > fs/iomap/buffered-io.c | 3 +++ > > 1 file changed, 3 insertions(+) > > > > diff --git a/fs/iomap/buffered-io.c b/fs/iomap/buffered-io.c > > index 3729391a18f3..fb4519158f3a 100644 > > --- a/fs/iomap/buffered-io.c > > +++ b/fs/iomap/buffered-io.c > > @@ -71,6 +71,9 @@ static void iomap_set_range_uptodate(struct folio *folio, size_t off, > > unsigned long flags; > > bool uptodate = true; > > > > + if (folio_test_uptodate(folio)) > > + return; > > + > > if (ifs) { > > spin_lock_irqsave(&ifs->state_lock, flags); > > uptodate = ifs_set_range_uptodate(folio, ifs, off, len); > > -- > > 2.49.0 > > > > > ---end quoted text---