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 2E6DDC77B73 for ; Tue, 30 May 2023 13:41:03 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 861F2900002; Tue, 30 May 2023 09:41:02 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7EB0A6B0074; Tue, 30 May 2023 09:41:02 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 63EE1900002; Tue, 30 May 2023 09:41:02 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 5579A6B0072 for ; Tue, 30 May 2023 09:41:02 -0400 (EDT) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 1BFCB1202F5 for ; Tue, 30 May 2023 13:41:02 +0000 (UTC) X-FDA: 80847032364.14.2B1BEDC Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by imf07.hostedemail.com (Postfix) with ESMTP id CFD7A40012 for ; Tue, 30 May 2023 13:40:59 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=VS5jzqUc; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=UgOrFUMD; dmarc=none; spf=pass (imf07.hostedemail.com: domain of dsterba@suse.cz designates 195.135.220.28 as permitted sender) smtp.mailfrom=dsterba@suse.cz ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1685454060; a=rsa-sha256; cv=none; b=wV/gbEegmgEAEd9FhJ0iDAuTFNF6hXg4YWIpIQbbNRWRW+OjzdgR+7XkfKf4IbXe65CQ4J psJL1U1m0q0nBoZDKCTzeIQm8PEg8NkeQp8pu2cA8LV1wURUcspG/XP2/wimJpeGjv5k6+ OZxmCBCKw3AGpsYxC2H4qih5C7PTlDY= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=VS5jzqUc; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=UgOrFUMD; dmarc=none; spf=pass (imf07.hostedemail.com: domain of dsterba@suse.cz designates 195.135.220.28 as permitted sender) smtp.mailfrom=dsterba@suse.cz ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1685454060; h=from:from:sender:reply-to: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=p+W1FxOLEOlkgtS4AADbLSxQOSBFLdK+zlfu8nmh3Dg=; b=upFt6Hj1DhSQuPf0b9wqnswYtwaGGZUW2HrzhbcQh9FdQOKePqp2n9Y8X7Ql2EukpL1PuD QaFrS9GIvj6fHIl9ASCPpFkopN8V2abx2eY+AYAZ4WV0SsbzuXO965q3zitxtDgwOfav8O LRPZeJeo0HAyXvOC0JF/uJncmIVuYuA= Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id E649D21A3D; Tue, 30 May 2023 13:40:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1685454057; h=from:from:reply-to: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=p+W1FxOLEOlkgtS4AADbLSxQOSBFLdK+zlfu8nmh3Dg=; b=VS5jzqUcngmsgR4VaCvG5zMFFlQ3cCzu4pWtMEXnGPIZV0xSitijGQYH+1p04QxC9txn5h Je3w6KpzVduQN5vpVBsqoAxYtXEhu4kcGgkvguGC3G0QilNL5vHhC8UnVYSq8Hp9io3s8k LjL6TSWIXMOWhk607+10spBjIG1nMw4= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1685454057; h=from:from:reply-to: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=p+W1FxOLEOlkgtS4AADbLSxQOSBFLdK+zlfu8nmh3Dg=; b=UgOrFUMD7U+PP7EM5NuZZI6llTZt+i9nBmrMhOTYmi+NsGSP8xdNdRhd49rvoVic2xeKtR Hee9Tjv9XN9N1wAg== Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id 8BDE813597; Tue, 30 May 2023 13:40:57 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id 6PNAIen8dWS+SAAAMHmgww (envelope-from ); Tue, 30 May 2023 13:40:57 +0000 Date: Tue, 30 May 2023 15:34:46 +0200 From: David Sterba To: Matthew Wilcox Cc: Christoph Hellwig , David Sterba , Chris Mason , Josef Bacik , David Sterba , linux-btrfs@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH 08/16] btrfs: stop setting PageError in the data I/O path Message-ID: <20230530133446.GR575@twin.jikos.cz> Reply-To: dsterba@suse.cz References: <20230523081322.331337-1-hch@lst.de> <20230523081322.331337-9-hch@lst.de> <20230529175210.GL575@twin.jikos.cz> <20230530054547.GA5825@lst.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23.1-rc1 (2014-03-12) X-Rspam-User: X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: CFD7A40012 X-Stat-Signature: aqgwfz3hdnrjojbfdi6z5r6ejtzdjpgy X-HE-Tag: 1685454059-881572 X-HE-Meta: U2FsdGVkX19X9Z+lKiv8ew9W53Gd4lNuIpPxpw+oCQpnKRy+vAZdBHgB4pKM8ULa1Qmi1Dy7+3utPV/1fT0YgMwN8rlWs9uxBg7/mRkQMLiUIAYVvkKGQK/vIoAbeFM6e2orza2tKVi5b65FfaD45QEN+s68zwSk9IBvKXLhTU7ke4znqipXjoBFjQWxIZow6zBH4ULczXVQeVP0yz2Dz6bjEMuGX+nU0ffx6mb5JSD7FrTStWasicATz3Pjzoz1452jUBQNp055GT6y3RZvxgN2dt9JCVtI0hy7vHqBFNsyoIj8740Xtziv/vLD8S1iDB9gW5LbU2IF6UegEUPB/koU2/yV4/7P7r40vkSJqt5c1WjHFlbo0z/aVBWHv9fE+6w0dQMMynDnfJe/YbbHB52XN7BVpoKsY2XTWzQxNQP/dUhTUXIw8tZzdplB4JeB5+avgQMkFYGoPgb926jQJDg8/g/fxLQQ5NAqEM9U6W6cP93RuYFou7laLdl9e2OD1G+j2hJq7pU/mRIXKC9j/uzEbsObkVN2qr4iLYn10uouUU8tba8Ep1SQpcS44/0PyJ3F0E1mP6Okm2muigs5OcpiqNwePVZ4dVQ8xt4/x0YESx17weCxgPSVbS0G/iqcmeKAfE1fAMc0XdjwEdhQ4iUOEdRunN/N18vuUV/WyyqcMBlU4365fFpZW5hKyjViBavHPKq3YmMQwbtQdL0KF9QqIwx7TW906nrpyn/rANFRb6y139JVD3j6C3/ivR49wCXoD3FTdZWQEajvYIc6kYpdgUkRL1eC0P79t/be9WVimU+0Qh9oPkqngz+omvGotUtl+yn/qWPUyzBDXvjCNoYiPXdToBOo+0dwZA3NinfKl6mDMCZPsK8Atz4ie3h/nBYQ54/A6uSTEi17BlzIdBKVT/qbZB93NOaT1TnxW+/UVuRe4V7Ph9piFwb+ZhMQe2UCEhS8l83AhnFHuWG CgzzKf4N Y3wm6/oORHY2P0XNrgxeRVsxocA1FXZ3rJ7hYplSIExmuF4SrN7jCWaZjiEzvoPQj6OOV10dZFVYb3LC7MWgClJhL2cHkpvDBGuz60MxcJd/hkf+OjwVtF9jMtkpVspKEE4gYoXPtPP0olm1CYrz8f7LhbXKqhDr9sGKqdRS9v+K0iCwGyihi6v4kJaoPZbWTyzvF3EtVtltjOkJw+0/LzJ8JQWCR5CFzfZuVqmpt0pgTneyaUSd7Nr2ecLO93HSQCLOb1C0/UZ0QMga4PVCVQaRCLR3gNHgJ96chTg/M7hy0bJ9PIkjDhEO4IA== 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: On Tue, May 30, 2023 at 07:08:38AM +0100, Matthew Wilcox wrote: > On Tue, May 30, 2023 at 07:45:47AM +0200, Christoph Hellwig wrote: > > On Mon, May 29, 2023 at 07:52:10PM +0200, David Sterba wrote: > > > On Tue, May 23, 2023 at 10:13:14AM +0200, Christoph Hellwig wrote: > > > > PageError is not used by the VFS/MM and deprecated. > > > > > > Is there some reference other than code? I remember LSF/MM talks about > > > writeback, reducing page flags but I can't find anything that would say > > > that PageError is not used anymore. For such core changes in the > > > neighboring subysystems I kind of rely on lwn.net, hearsay or accidental > > > notice on fsdevel. > > > > > > Removing the Error bit handling looks overall good but I'd also need to > > > refresh my understanding of the interactions with writeback. > > > > willy is the driving force behind the PageErro removal, so maybe he > > has a coherent writeup. But the basic idea is: > > > > - page flag space availability is limited, and killing any one we can > > easily is a good thing > > - PageError is not well defined and not part of any VM or VFS contract, > > so in addition to freeing up space it also generally tends to remove > > confusion. > > I don't think I have a coherent writeup. Basically: > > - The VFS and VM do not check the error flag > > $ git grep folio_test_error > fs/gfs2/lops.c: if (folio_test_error(folio)) > mm/migrate.c: if (folio_test_error(folio)) > > (the use in mm/migrate.c replicates the error flag on migration) > > A similar grep -w PageError finds only tests in filesystems and > comments. > > - We do not document clearly under what circumstances the error flag > is set or cleared > > If we can remove all uses of testing the error flag, then we can remove > everywhere that sets or clears the flag. This is usually a simple > matter of checking folio_test_uptodate() instead of !PageError(), > since the folio will not be marked uptodate if there is a read error. > Write errors are not normally tracked on a per-folio basis. Instead they > are tracked through mapping_set_error(). > > I did a number of these conversions about a year ago; I'm happy Christoph > is making progress with btrfs here. See 'git log 6e8e79fc8443' for many > of them. Thank you, that helped. I found one case of folio_set_error() that seems to be redundant: 189 static noinline void end_compressed_writeback(const struct compressed_bio *cb) 190 { 191 struct inode *inode = &cb->bbio.inode->vfs_inode; 192 struct btrfs_fs_info *fs_info = btrfs_sb(inode->i_sb); 193 unsigned long index = cb->start >> PAGE_SHIFT; 194 unsigned long end_index = (cb->start + cb->len - 1) >> PAGE_SHIFT; 195 struct folio_batch fbatch; 196 const int errno = blk_status_to_errno(cb->bbio.bio.bi_status); 197 int i; 198 int ret; 199 200 if (errno) 201 mapping_set_error(inode->i_mapping, errno); 202 203 folio_batch_init(&fbatch); 204 while (index <= end_index) { 205 ret = filemap_get_folios(inode->i_mapping, &index, end_index, 206 &fbatch); 207 208 if (ret == 0) 209 return; 210 211 for (i = 0; i < ret; i++) { 212 struct folio *folio = fbatch.folios[i]; 213 214 if (errno) 215 folio_set_error(folio); ^^^^^^^^^^^^^^^^^^^^^^^ The error is set on the mapping on line 201 under the same condition. With that removed and the super block write error handling moved away from the Error bit the btrfs code will be Error-clean. 216 btrfs_page_clamp_clear_writeback(fs_info, &folio->page, 217 cb->start, cb->len); 218 } 219 folio_batch_release(&fbatch); 220 } 221 /* the inode may be gone now */ 222 }