From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from verein.lst.de (verein.lst.de [213.95.11.211]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7F53C2AF19 for ; Thu, 3 Jul 2025 13:05:06 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=213.95.11.211 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1751547908; cv=none; b=ehCsanavCyHVl+gRiUoTCYHQExphzNinp/5Th7b26X4+QmzgqPvta8smV9lLKpqb6JMmoRutGNxS0VxOBZzm/+XJiHGwO3QtBHCk7MI0XOjmyVbGb9ep1sbaJZFprBFjkLc8d3ANdi0JpShENtT9Ptm/CKaFO2/hkhJ8iPTW8/w= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1751547908; c=relaxed/simple; bh=riu/oMZ4j8xMs0NKvk5hrwihCj5mHKuM//UsRwhQRF0=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=nCd/eeFEVJCZmsMgLjOctZ+G3RFjA2B3UgASMQfkDBoPpOtnmnLds6K1PZJckLZV2VRofXd96TYQKk8Fo6k8mOp4IFjufTUCPVuqdG2W5Uug5+8eLKfktPCKFvhGDqnH9XOEsTFNEFCo6ZqRZPulqu/8xHGgbvgN4apJdp9rNDY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=lst.de; spf=pass smtp.mailfrom=lst.de; arc=none smtp.client-ip=213.95.11.211 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=lst.de Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=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> Precedence: bulk X-Mailing-List: gfs2@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: 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) 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. 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 lists.sourceforge.net (lists.sourceforge.net [216.105.38.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id A83C8C77B7C for ; Thu, 3 Jul 2025 13:05:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.sourceforge.net; s=beta; h=Content-Transfer-Encoding:Content-Type:Cc: List-Subscribe:List-Help:List-Post:List-Archive:List-Unsubscribe:List-Id: Subject:In-Reply-To:MIME-Version:References:Message-ID:To:From:Date:Sender: Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender :Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=yRy3AUFy3O78n7OwATkmpRmQD7Tw4UXcA//QX/N7R/M=; b=exo85M0wp4gvuLqiUYyfxIPUT9 5lzxH4C83mtOhtcQrMdU82ongT6yIcCoeqJkrogrgEDFbsOF0PzyMHcAE529or7xFdT24sYxcEqNK MCYnmPFTvB8JR6LJUWXx6CX8qKkzYztHo8rSTq8PEmivhJfNLzTadg5P9yvWH+dT37qM=; Received: from [127.0.0.1] (helo=sfs-ml-3.v29.lw.sourceforge.com) by sfs-ml-3.v29.lw.sourceforge.com with esmtp (Exim 4.95) (envelope-from ) id 1uXJcr-0007mp-Ek; Thu, 03 Jul 2025 13:05:17 +0000 Received: from [172.30.29.66] (helo=mx.sourceforge.net) by sfs-ml-3.v29.lw.sourceforge.com with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1uXJcq-0007mj-Ji for linux-f2fs-devel@lists.sourceforge.net; Thu, 03 Jul 2025 13:05:16 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sourceforge.net; s=x; h=In-Reply-To:Content-Type:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=v+kiTNw6gsKn4FIH6q/9gpLZes6iK7KPLf4EnRpYFjU=; b=AJpl3NJvlLq3+77ley1W5VHZJS MpAz7j0uULb6JUxA6C37IOHyXPw6K4OsiL9947WGkkkPFI2YZCDvn7fwc+hvWVopka1KRxic822cS e/CzK8Gy+J8fYg58LR9p3Iyvu1aQpArVT/gl0NB/iqxkKGcCZnm4iVcdV6qtNpk5Vyt0=; DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sf.net; s=x ; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To :From:Date:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=v+kiTNw6gsKn4FIH6q/9gpLZes6iK7KPLf4EnRpYFjU=; b=G/OTu+/RUWxqvubXeM8qDjzfv5 I69l+uIH5FHkBans2N676V1B9Q/hYS64OAbta3Gi7KCLHQgp+4mQPDW2eJK/RBSvG4eFpOj4QsWE9 OzXJFuxezuUR7+r/Y7sSKgi8B/khX4LifnpzAJJ3wwjcyJyKXtFMHrk7Ydry/2tjMSuY=; Received: from verein.lst.de ([213.95.11.211]) by sfi-mx-2.v28.lw.sourceforge.com with esmtps (TLS1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.95) id 1uXJcp-00026S-Td for linux-f2fs-devel@lists.sourceforge.net; Thu, 03 Jul 2025 13:05:16 +0000 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" 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-Disposition: inline In-Reply-To: <20250702184312.GC9991@frogsfrogsfrogs> User-Agent: Mutt/1.5.17 (2007-11-01) X-Headers-End: 1uXJcp-00026S-Td Subject: Re: [f2fs-dev] [PATCH 00/13] Parallelizing filesystem writeback X-BeenThere: linux-f2fs-devel@lists.sourceforge.net X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: ritesh.list@gmail.com, jack@suse.cz, amir73il@gmail.com, david@fromorbit.com, gfs2@lists.linux.dev, linux-mm@kvack.org, clm@meta.com, hch@lst.de, dave@stgolabs.net, agruenba@redhat.com, miklos@szeredi.hu, Kundan Kumar , willy@infradead.org, p.raghav@samsung.com, linux-nfs@vger.kernel.org, da.gomez@samsung.com, viro@zeniv.linux.org.uk, Kundan Kumar , jaegeuk@kernel.org, axboe@kernel.dk, brauner@kernel.org, linux-f2fs-devel@lists.sourceforge.net, mcgrof@kernel.org, anna@kernel.org, gost.dev@samsung.com, linux-fsdevel@vger.kernel.org, Andrew Morton , trondmy@kernel.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: linux-f2fs-devel-bounces@lists.sourceforge.net 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. _______________________________________________ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel