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 67A57C77B7C for ; Thu, 3 Jul 2025 13:05:11 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D99396B00C3; Thu, 3 Jul 2025 09:05:10 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D6F656B00D2; Thu, 3 Jul 2025 09:05:10 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CABE76B00FC; Thu, 3 Jul 2025 09:05:10 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id BA5D46B00C3 for ; Thu, 3 Jul 2025 09:05:10 -0400 (EDT) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 3D81A578B7 for ; Thu, 3 Jul 2025 13:05:10 +0000 (UTC) X-FDA: 83622973980.02.8196647 Received: from verein.lst.de (verein.lst.de [213.95.11.211]) by imf14.hostedemail.com (Postfix) with ESMTP id 12C92100012 for ; Thu, 3 Jul 2025 13:05:07 +0000 (UTC) Authentication-Results: imf14.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=lst.de; spf=pass (imf14.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=1751547908; 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=v+kiTNw6gsKn4FIH6q/9gpLZes6iK7KPLf4EnRpYFjU=; b=Hl3nU3k4PB0NGEx2wwDrm8wJmnUkdAK0PXyKYUAVeeTqospXdCjyhxTK8RTnbCrwI2xBrR WdNSQWY7U3wouZeGd7R1QODGufnatLxkTgeg6nDKXkg6qfgauqfxZ4Q46ydVkF+rTXCjPL ze0Wrp1mii12f9HNRNwwlDw37q32Wy4= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1751547908; a=rsa-sha256; cv=none; b=zshSyIlW8MeKGyULOHsw8Oh2FYzUoMcdZ28jJV2MtkXFTLCRq/2WtjjtrFo4sWrBcyeb+/ kYwzgiCDGJzlbOy0k1xL0N1enB8Q9iNDOFslla034H3FuXzUg2RGIAgwhOlbnLe5jL6b4/ KU/ukYh1x2aspi2WtzOichSG3sAdqXA= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=lst.de; spf=pass (imf14.hostedemail.com: domain of hch@lst.de designates 213.95.11.211 as permitted sender) smtp.mailfrom=hch@lst.de Received: by verein.lst.de (Postfix, from userid 2407) id 5035468BFE; Thu, 3 Jul 2025 15:05:00 +0200 (CEST) Date: Thu, 3 Jul 2025 15:05:00 +0200 From: Christoph Hellwig To: "Darrick J. Wong" Cc: Kundan Kumar , Andrew Morton , 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, willy@infradead.org, mcgrof@kernel.org, clm@meta.com, david@fromorbit.com, amir73il@gmail.com, axboe@kernel.dk, hch@lst.de, ritesh.list@gmail.com, 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 Subject: Re: [PATCH 00/13] Parallelizing filesystem writeback Message-ID: <20250703130500.GA23864@lst.de> References: <20250529111504.89912-1-kundan.kumar@samsung.com> <20250529203708.9afe27783b218ad2d2babb0c@linux-foundation.org> <20250702184312.GC9991@frogsfrogsfrogs> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20250702184312.GC9991@frogsfrogsfrogs> User-Agent: Mutt/1.5.17 (2007-11-01) X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 12C92100012 X-Stat-Signature: pzhxrt49rm9y6dd6qowz6mne1hhcmsyy X-Rspam-User: X-HE-Tag: 1751547907-197429 X-HE-Meta: U2FsdGVkX1+Eh8sM0bqgIjWNeHywenDNlxgYrBpg4zMWwKRaBqNil0s6clnieqvd8s9xkpfTeuzI3MKC9lpnFJQp/A/kduc2ElMyviP6AuLY8oRftQI8CnhnRfT7I/142T3H9JTDM4fR9UKNTSjrCx/4nF7SRU1sVwW4q1LeFZEcNZUytB339nFl5lLjApLQAjMQkLA8Q6Yvg4piZCAdUwOnNiDszc1DT67KK8IIHGmoqB1nXasEf2sbnW4tzxolNKCTzRqsrPN6LQD7yNct1LoiitIGf7hbUyfutgXaKINeQBUYQBmiUEbU5E0Ncdnt8T2SPSgJ4S/UmFJARnKDCOwDgeyVdBUNT7Yzs3yX5XEIZuvDT7t2E1uhj00LbOWezAp06Ww7uI+Z5CTgeGGfBmDkBReNDXgXE4y/CjAzMO/zy2j0xbT3XKuhVYlaub4M9oZ2AywmWutWle/sXtM37nzaR/+dFxZJa2CO/xehlDvv0dC/plxPXjXTA/yBpWXLeJrKFGlBEHV1ThG8BmSTLbsEf8pqeoYKpTJiwTkB54xfgzFEGI2jbFhmgxpfX667p6dozyp638SBnAUJNyUUsp2FXa4/IOBbZSuJMQtENxYG8i0dW8VvYr3SQedOgipN01hQ1aH5X63whZ+AcFlegpDeO6Da/uVQA21HkD0aItQVNBfHUDGzJledvQv+2v0R+C+YoOSehoNDBqVZFgimUTCTUGplfhPbGSaUPRBTFPdR4+Ae6xcWTG1VdiwXTUVjrnEa9X8Q43PPSA3W87nz+8vk0H2u13K8a39SZqhoDR+mUn7awQQekAfJl7ouzbSkYkG2Lj3IpJHlXigYJccm26iv/zc3K3XrDfLPkXkgmRlS/pwUV6clZ8EspEt6U9D8Tx2fbBOMqydQE2hVSvVIqBCoy8D9zraMSplyzOUbuSZUum5bydcdw8B83Sqb6ioKvJ6z9RSEgfIkvS1VrdL MIWre05r dAs92HPIR0hGs+qZJMyXhTm8dZ6ICGAWzFzwMFJ9BZ2/mSjosT9D9TWRavR4+r9qVrCndJNZQQnvur5/KT0J81A6zXDrnr6fp7aaMEKN49fi8crxG4AgQfmpmcfH18zn/T+z6IQCPZI+4SfNwF73KWjtPFZEXKktd2pgbJXDWJINIYKI= 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, Jul 02, 2025 at 11:43:12AM -0700, Darrick J. Wong wrote: > > On a spinning disk, random IO bandwidth remains unchanged, while sequential > > IO performance declines. However, setting nr_wb_ctx = 1 via configurable > > writeback(planned in next version) eliminates the decline. > > > > echo 1 > /sys/class/bdi/8:16/nwritebacks > > > > We can fetch the device queue's rotational property and allocate BDI with > > nr_wb_ctx = 1 for rotational disks. Hope this is a viable solution for > > spinning disks? > > Sounds good to me, spinning rust isn't known for iops. > > Though: What about a raid0 of spinning rust? Do you see the same > declines for sequential IO? Well, even for a raid0 multiple I/O streams will degrade performance on a disk. Of course many real life workloads will have multiple I/O streams anyway. I think the important part is to have: a) sane defaults b) an easy way for the file system and/or user to override the default For a) a single thread for rotational is a good default. For file system that driver multiple spindles independently or do compression multiple threads might still make sense. For b) one big issue is that right now the whole writeback handling is per-bdi and not per superblock. So maybe the first step needs to be to move the writeback to the superblock instead of bdi? If someone uses partitions and multiple file systems on spinning rusts these days reducing the number of writeback threads isn't really going to save their day either.