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 36711C5AD49 for ; Tue, 3 Jun 2025 13:24:43 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C613D6B044D; Tue, 3 Jun 2025 09:24:42 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C0E236B044E; Tue, 3 Jun 2025 09:24:42 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B24226B044F; Tue, 3 Jun 2025 09:24:42 -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 934C26B044D for ; Tue, 3 Jun 2025 09:24:42 -0400 (EDT) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 3304E12099D for ; Tue, 3 Jun 2025 13:24:42 +0000 (UTC) X-FDA: 83514159204.12.9C8435F Received: from verein.lst.de (verein.lst.de [213.95.11.211]) by imf15.hostedemail.com (Postfix) with ESMTP id 8D6E7A0009 for ; Tue, 3 Jun 2025 13:24:40 +0000 (UTC) Authentication-Results: imf15.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=lst.de; spf=pass (imf15.hostedemail.com: domain of hch@lst.de designates 213.95.11.211 as permitted sender) smtp.mailfrom=hch@lst.de ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1748957080; 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; bh=QfdJcMtitqVv2K9sFm4dcEYmSiJwmxzfWqAeWpKi4OE=; b=B5pF4gnZcwW8R21pXc4SxqjkdtgyxbuPeKhAixFg6LXAWRkn/mWpkwWPW5vYdgURlx9EWZ 9ewgqb4nYJnLokDn7UnuCTvX5HdT+FmUUnon8BhYWjcsCbTPASSRE2d6ldeXI8hkGE92lR Q869h7srquM/1nOLxzfYUqza4+Pe0Xs= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=lst.de; spf=pass (imf15.hostedemail.com: domain of hch@lst.de designates 213.95.11.211 as permitted sender) smtp.mailfrom=hch@lst.de ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1748957080; a=rsa-sha256; cv=none; b=N/Wr1bFJ8eC+5dXmmAvK2plqMHGnz/MUMAB/413LcBEzWVfgtO3lEM28WkwjaiadosDR1s YXNHWO/JYlvNCobTRaMZ1t/NpPDTehEXCQH0F8Nie5B5kRye5hzEOb3KXM/Tfjh7QaS8n/ jDioWoTg1BzRqbfiUWgNnHK5IzxNU6s= Received: by verein.lst.de (Postfix, from userid 2407) id D45DF68D0F; Tue, 3 Jun 2025 15:24:34 +0200 (CEST) Date: Tue, 3 Jun 2025 15:24:34 +0200 From: Christoph Hellwig To: Anuj Gupta/Anuj Gupta Cc: Christoph Hellwig , Kundan Kumar , jaegeuk@kernel.org, chao@kernel.org, viro@zeniv.linux.org.uk, brauner@kernel.org, jack@suse.cz, miklos@szeredi.hu, agruenba@redhat.com, trondmy@kernel.org, anna@kernel.org, akpm@linux-foundation.org, willy@infradead.org, mcgrof@kernel.org, clm@meta.com, david@fromorbit.com, amir73il@gmail.com, axboe@kernel.dk, ritesh.list@gmail.com, djwong@kernel.org, dave@stgolabs.net, p.raghav@samsung.com, da.gomez@samsung.com, linux-f2fs-devel@lists.sourceforge.net, linux-fsdevel@vger.kernel.org, gfs2@lists.linux.dev, linux-nfs@vger.kernel.org, linux-mm@kvack.org, gost.dev@samsung.com, anuj1072538@gmail.com, kundanthebest@gmail.com Subject: Re: [PATCH 00/13] Parallelizing filesystem writeback Message-ID: <20250603132434.GA10865@lst.de> References: <20250529111504.89912-1-kundan.kumar@samsung.com> <20250602141904.GA21996@lst.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: 8D6E7A0009 X-Stat-Signature: qmc6r4aahtycnxpmu53n18bww39kg18a X-Rspam-User: X-HE-Tag: 1748957080-716428 X-HE-Meta: U2FsdGVkX19gjqOFOvYBaxpS95H9527iOEz5H+xM/8i7hfSBhzE4WawQcBLtEiv7/mwMgdeqsZEC4SYBYMMNGKHdCx+VghZ56apw4/nKR5/nipcXwJZtRqEpU3GRXKn5XNxUM269GrmohCItlBLMX5b0AvC1RMk5+g8nKUXx7EIPI//a6bHLv5JSLz4iT3i1FEbiJp7ASnr75UuDr6/j957BEHMmUvtXIUvlu9y7pmu/YDIzf4z83CiL03J60bET00WScCbj8K18K07ch9prFoSGoZww9P9tU8SDb2gl9LlH+k1HAkDb49SzXgyCn7W+3aB3EvTzGAxD66ryB5jnsYuQbq5Uvg1KCxqD/0FTxvbmH2mMT+6p9WHqJbc+57AAurgqTzMW5HUktSLmp8UcAzcBXLY3Xap4cmsRQeWIPMM9X6FjuoMMZnOynW+UjC89XGX9Qe6UnGCve8NEaHIk4dC6BEr4nzgbM0RxX/Mxlt/wHXXzgL0N6QWjaN5rvQ+yFKKgtvD8zxwjXbbkWvuRJxH3BcG5qYH4RRZYkJiYXlyDCm6yRtaKelcXIn5cmh1nu4C6QfKi20OjOgpHqKHDAEZWLd9Ui1+E9CkOTx5DvAK45vXkojA1Wco8Asz198AhYIbkY80/obBSw6ZPvrS/GN+Nnj4C+ORmaTeZJHgoJ+hFPraMnaOlGbWs1f6uYu8Q9NTTDHhRQGpOcQuXQL5+hBH/dB0PeVP1E7BqWs/1yDQjAgNDLAljSuHHAfxRgPKLbq6Q9aeIJxBIPQoOw/pg36YqN2ry5HmAfYWY6waBDvv8wcGmJFLziL4EFNzmnp4zGmFIPCQOoZgXmd/3Sbjdj+L+gc/EZgsTvXeTjouGqSiBprqUgiDNUQ== 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 Tue, Jun 03, 2025 at 02:46:20PM +0530, Anuj Gupta/Anuj Gupta wrote: > On 6/2/2025 7:49 PM, Christoph Hellwig wrote: > > On Thu, May 29, 2025 at 04:44:51PM +0530, Kundan Kumar wrote: > > Well, the proper thing would be to figure out a good default and not > > just keep things as-is, no? > > We observed that some filesystems, such as Btrfs, don't benefit from > this infra due to their distinct writeback architecture. To preserve > current behavior and avoid unintended changes for such filesystems, > we have kept nr_wb_ctx=1 as the default. Filesystems that can take > advantage of parallel writeback (xfs, ext4) can opt-in via a mount > option. Also we wanted to reduce risk during initial integration and > hence kept it as opt-in. A mount option is about the worst possible interface for behavior that depends on file system implementation and possibly hardware chacteristics. This needs to be set by the file systems, possibly using generic helpers using hardware information. > Used PMEM of 6G battery/capacitor backed DRAM, or optane? > > and NVMe SSD of 3.84 TB Consumer drive, enterprise drive? > For xfs used this command: > xfs_io -c "stat" /mnt/testfile > And for ext4 used this: > filefrag /mnt/testfile filefrag merges contiguous extents, and only counts up for discontiguous mappings, while fsxattr.nextents counts all extent even if they are contiguous. So you probably want to use filefrag for both cases.