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 4BF46C3601E for ; Thu, 10 Apr 2025 14:38:41 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4EE88280107; Thu, 10 Apr 2025 10:38:40 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 49C9F280103; Thu, 10 Apr 2025 10:38:40 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 33E63280107; Thu, 10 Apr 2025 10:38:40 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 1627F280103 for ; Thu, 10 Apr 2025 10:38:40 -0400 (EDT) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 025D6ADE2A for ; Thu, 10 Apr 2025 14:38:39 +0000 (UTC) X-FDA: 83318390400.14.E7AE872 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.223.130]) by imf26.hostedemail.com (Postfix) with ESMTP id B343514000F for ; Thu, 10 Apr 2025 14:38:37 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b="WC/SgvIy"; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=i6tUqsvd; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=JU+hH6VE; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=B2m2WZbt; spf=pass (imf26.hostedemail.com: domain of jack@suse.cz designates 195.135.223.130 as permitted sender) smtp.mailfrom=jack@suse.cz; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1744295918; 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=CU5ScoH+7UlhrYAQP6ak2OPq7M4zSmzWu8pSjfnrvkg=; b=DqDnzzrvywSiFWIvIWHVkHf4OdjcvHKQGXpAMUCNHki3zAQQo9Ny//b98fRihYsV69Dt53 V4d/VgSAS0r1r12+jV0+qqVWLdHwxD3weR6WBX14kb14WQv0nFyZlCFF+QlN5ibzJUDA8V jSUa/PxTo/AM8WSNTmb4rKC2cKr9GUw= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b="WC/SgvIy"; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=i6tUqsvd; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=JU+hH6VE; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=B2m2WZbt; spf=pass (imf26.hostedemail.com: domain of jack@suse.cz designates 195.135.223.130 as permitted sender) smtp.mailfrom=jack@suse.cz; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1744295918; a=rsa-sha256; cv=none; b=TMUHaWvFFmlk8tsKN3BsLGQYHodPR8RhYSBFhiZR13qlxHPQ7AoWIF5ODJjTuX9vamqYXL +WkXrZvpQ4KkxgeBk80mqBlb8Wf3jwjX8yLm8uf5dF8QzRK5T/DovEsIylBJHzQSGr5RXg R88gWXT6WrbUiBe/E/TKHyl99xpf1yU= Received: from imap1.dmz-prg2.suse.org (unknown [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 D3E5C21164; Thu, 10 Apr 2025 14:38:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1744295916; 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=CU5ScoH+7UlhrYAQP6ak2OPq7M4zSmzWu8pSjfnrvkg=; b=WC/SgvIyNSeYBd6tKbYkdnCZkVBeEPO0SPZg1HZDQlcxer6rA3ope+Ci52owutHqzddfCg OoLq7NE30dZmUeAoQD8KV542krQB9fyuvEyj6a20c6HUbRLHyvzizsCH7Zv60crnn5qZox a79fRZdpcH5lT9/hG6d05LkIaBn+mlI= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1744295916; 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=CU5ScoH+7UlhrYAQP6ak2OPq7M4zSmzWu8pSjfnrvkg=; b=i6tUqsvdtxKiWoZGx11+Evk83U+67+43WjCVvZC7ATyCm82BJ9vGXHxoXoZ/hfTTH+HyYv x8ABpFSwajS/tCAA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1744295915; 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=CU5ScoH+7UlhrYAQP6ak2OPq7M4zSmzWu8pSjfnrvkg=; b=JU+hH6VEzW+1J7sGX6bI6F9ze22i6ENNW/MEb8z1gtKGbVDezZIg4cRflK1Q2dWzil74yv 7xbyLpLwRht7xfcHWNnAo2FhhtiRwaZp5e7DtV3ZaL3zVtB0ET5gUs5c/8QYG3Eelf+Lda f2zoURxsz633GFRzqfiSihnIvdCtddk= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1744295915; 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=CU5ScoH+7UlhrYAQP6ak2OPq7M4zSmzWu8pSjfnrvkg=; b=B2m2WZbtJKSCmtj2t6MlfvZdRMenks/oADjKbNb+OFJUWNJeuvBMHJ9U2e5fwLdv8dRWkq 7Ae56jSV15vrKEBg== 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 C170113886; Thu, 10 Apr 2025 14:38:35 +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 ZVEsL+vX92eFfgAAD6G6ig (envelope-from ); Thu, 10 Apr 2025 14:38:35 +0000 Received: by quack3.suse.cz (Postfix, from userid 1000) id 316AAA07A7; Thu, 10 Apr 2025 16:38:35 +0200 (CEST) Date: Thu, 10 Apr 2025 16:38:35 +0200 From: Jan Kara To: Luis Chamberlain Cc: brauner@kernel.org, jack@suse.cz, tytso@mit.edu, adilger.kernel@dilger.ca, linux-ext4@vger.kernel.org, riel@surriel.com, dave@stgolabs.net, willy@infradead.org, hannes@cmpxchg.org, oliver.sang@intel.com, david@redhat.com, axboe@kernel.dk, hare@suse.de, david@fromorbit.com, djwong@kernel.org, ritesh.list@gmail.com, linux-fsdevel@vger.kernel.org, linux-block@vger.kernel.org, linux-mm@kvack.org, gost.dev@samsung.com, p.raghav@samsung.com, da.gomez@samsung.com Subject: Re: [PATCH v2 2/8] fs/buffer: try to use folio lock for pagecache lookups Message-ID: References: <20250410014945.2140781-1-mcgrof@kernel.org> <20250410014945.2140781-3-mcgrof@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20250410014945.2140781-3-mcgrof@kernel.org> X-Rspamd-Queue-Id: B343514000F X-Rspamd-Server: rspam05 X-Rspam-User: X-Stat-Signature: ecu13ukgptx315mgzuq67om5rxmj1smx X-HE-Tag: 1744295917-259126 X-HE-Meta: U2FsdGVkX18Ca7fbFPCrcMPmccuTvkGfInAK8eBo8BzpmumFE2iYOijoEFLfRRVAV4nsyAilL61SLcO6CVdPEO3E7yjCTPtEbQzRkllY/jouAFDg6gHdZSfjD4Z4j8YMREd8NSXaRabJTZs2FFImt2R/UGWrGAn7xD7eIeCGDbgYjD2+jyvH/NeqHvdzD/kQeq4rBGBH3zYsojhcp6t9UA1iHIDcdGFyA4grs7ekEkuiC7+sjvOnACNuIjVRKo+ev+LvMHvAeH5TvUIwH30PZVx5nZIa9XBWM3olj9PR4onbD0ak1H6sD7kk4zvQPVhuLIzSShKM9SEbVZveAj8sLb3HWbl79aTz8sDfsGFCE/BYLq+agTJFXSbqTuQEIgWz6FulRKyUrPeYbUUPJYZiRe2CYmp8D6Fu98e9RpCkv12403E/8pMnhDp9TMVgpYb9Co32aafXYmVyzS9OW7YXpwiqGRjjCi45WZYj8c1jm1uEZqdp6Dtvn1vngAEwS/7QvH+zuAQ10RkzpjtZ0NnqlyGkXhE8pX3MnadsRpM5ySiUbxkUem2DZPptRvqw50InEPtLKPoBLZau4CJEtjQ+BowTZCSVBGgN1xB5GDs2FJbmrQ9vzpiRpuA5yXDOL9TxQW3VvCzKsU4q95dBOyn57y4lgTSwp5ZkspXjZ/OGGX52GSNsan0lRCFpi2Gel2QY8ALorvlKB7gRxRhM8hoDCZmL8WQjD+h2TG2YIQ0eT6JLuNHn134NrRo9FIEGgweU8DmRO7jmcR6iF+qIC7LkVvtAnHGJ2TArOfgicA4W/L6euK8T6AJxIGTDzoxhzhH9IfmYe49DbMJU9uIvWPNeJ5wAso3BgsqVTfYi127EQm/V+XZxIKnx4xKBInGNFeLMhfRGjF6gs0fC/Ng40/m+1MjNUl4JkegPv/2bSR+mac9V6cJpLfZzc8vjWo+vIxcV02y5EKT/hRm9SiMsbMt HFE/u3hQ FDaG5xpX1T5YgIXICZOFO7KhL+heilU4Tf8BexQUNpDQOoX8oea5gujDQMs4ewWLSL3aNLe9HbKUJZUy4Sd+5QjkPhWsyL/OEfh3mvkWBcP1zyJBMdVV4HGiouIVbkPcjF7RzanMpzx+7VfgInIqdAaZp7/epxVVR3vPynyi7tVo3djsjr66xvp7AdQTBix60SWwG76jg7r9eyO6/gqq2gvWpabGnzjoTBj30PGq1PO3zPGN8SXdoKisuFVgK2eOlz4yAKmfcWj1jgNn02btB295D1FJOPESwR+TwEmfMVSCPIEI+NgpPFDYBUN8FL4q5rKZT0GvujTZQB8s5QHIyu5om4TK+myo0E6/hoBj5cp/4QCVmcS0eTCk+ZH+OHbj/SSdEEhBCVxOQl8urrE7HmQI6IG7I3hKKaslud1aO6vKkba24sOEKxP+XCw49WVOVt+qCi/d0PUbdE+98aTn4Y+fHT3k7nyyBdHDRM45I28iCAG8= 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 Wed 09-04-25 18:49:39, Luis Chamberlain wrote: > From: Davidlohr Bueso > > Callers of __find_get_block() may or may not allow for blocking > semantics, and is currently assumed that it will not. Layout > two paths based on this. Ultimately the i_private_lock scheme will > be used as a fallback in non-blocking contexts. Otherwise > always take the folio lock instead. The suggested trylock idea > is implemented, thereby potentially reducing i_private_lock > contention in addition to later enabling future migration support > around with large folios and noref migration. > > No change in semantics. All lookup users are non-blocking. > > Signed-off-by: Davidlohr Bueso > Signed-off-by: Luis Chamberlain ... > @@ -204,7 +195,19 @@ __find_get_block_slow(struct block_device *bdev, sector_t block) > if (IS_ERR(folio)) > goto out; > > - spin_lock(&bd_mapping->i_private_lock); > + /* > + * Folio lock protects the buffers. Callers that cannot block > + * will fallback to serializing vs try_to_free_buffers() via > + * the i_private_lock. > + */ > + if (!folio_trylock(folio)) { > + if (atomic) { > + spin_lock(&bd_mapping->i_private_lock); > + folio_locked = false; > + } else > + folio_lock(folio); > + } Ewww, this is going to be pain. You will mostly use the folio_trylock() for protecting the lookup, except when some insane workload / fuzzer manages to trigger the other path which will lead to completely unreproducible bugs... I'd rather do: if (atomic) { spin_lock(&bd_mapping->i_private_lock); folio_locked = false; } else { folio_lock(folio); } I'd actually love to do something like: if (atomic) { if (!folio_trylock(folio)) bail... } else { folio_lock(folio); } but that may be just too radical this point and would need some serious testing how frequent the trylock failures are. No point in blocking this series with it. So just go with the deterministic use of i_private_lock for atomic users for now. Honza > + > head = folio_buffers(folio); > if (!head) > goto out_unlock; > @@ -236,7 +239,10 @@ __find_get_block_slow(struct block_device *bdev, sector_t block) > 1 << blkbits); > } > out_unlock: > - spin_unlock(&bd_mapping->i_private_lock); > + if (folio_locked) > + folio_unlock(folio); > + else > + spin_unlock(&bd_mapping->i_private_lock); > folio_put(folio); > out: > return ret; > @@ -1388,14 +1394,15 @@ lookup_bh_lru(struct block_device *bdev, sector_t block, unsigned size) > * it in the LRU and mark it as accessed. If it is not present then return > * NULL > */ > -struct buffer_head * > -__find_get_block(struct block_device *bdev, sector_t block, unsigned size) > +static struct buffer_head * > +find_get_block_common(struct block_device *bdev, sector_t block, > + unsigned size, bool atomic) > { > struct buffer_head *bh = lookup_bh_lru(bdev, block, size); > > if (bh == NULL) { > /* __find_get_block_slow will mark the page accessed */ > - bh = __find_get_block_slow(bdev, block); > + bh = __find_get_block_slow(bdev, block, atomic); > if (bh) > bh_lru_install(bh); > } else > @@ -1403,6 +1410,12 @@ __find_get_block(struct block_device *bdev, sector_t block, unsigned size) > > return bh; > } > + > +struct buffer_head * > +__find_get_block(struct block_device *bdev, sector_t block, unsigned size) > +{ > + return find_get_block_common(bdev, block, size, true); > +} > EXPORT_SYMBOL(__find_get_block); > > /** > -- > 2.47.2 > -- Jan Kara SUSE Labs, CR