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 00D0E2D949B for ; Mon, 7 Jul 2025 14:28:15 +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=1751898497; cv=none; b=GWPGJRAt/8tP3VGd+VgZi4PaAtM8AaQiwA6MZCvicLz6FzVqTIdqZCbDjklh9xAoaffPmsKdtJjVQ8y1gLGAd9rKnxxOHdjk42x48A+yT2M0rBxy00pIqgKpYUqi/Bd0c4TDq0AEkIEb6OLlL89m7rpZXNqoT4wqcTSTJHLCmqQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1751898497; c=relaxed/simple; bh=oLaPuwfjVO73biwwsB01ZxZBB9jRIqrj9ERo8AWuhBM=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=mUR8p5KHyW4eFP6HUZM45wNUtOiIfo8m5LN3QxEWhgo3st4te1A21WQzVXlDVWW+4L/Dy9kUCgXq6PfQQZCfdsSELYGmfOB8C2Wm9ot0l//FuJfRjoTX5z2fKGSZrGG6wjdxahsRqU6W/USoLTYLaHXwyWbqUo4dHVVEJS2EYSk= 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 6B34E68C7B; Mon, 7 Jul 2025 16:28:09 +0200 (CEST) Date: Mon, 7 Jul 2025 16:28:09 +0200 From: Christoph Hellwig To: Kundan Kumar Cc: Christoph Hellwig , "Darrick J. Wong" , Andrew Morton , Kundan Kumar , jaegeuk@kernel.org, chao@kernel.org, viro@zeniv.linux.org.uk, Christian Brauner , jack@suse.cz, miklos@szeredi.hu, agruenba@redhat.com, Trond Myklebust , anna@kernel.org, Matthew Wilcox , mcgrof@kernel.org, clm@meta.com, david@fromorbit.com, amir73il@gmail.com, Jens Axboe , 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: <20250707142809.GA31459@lst.de> References: <20250529111504.89912-1-kundan.kumar@samsung.com> <20250529203708.9afe27783b218ad2d2babb0c@linux-foundation.org> <20250702184312.GC9991@frogsfrogsfrogs> <20250703130500.GA23864@lst.de> 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: User-Agent: Mutt/1.5.17 (2007-11-01) On Fri, Jul 04, 2025 at 12:32:51PM +0530, Kundan Kumar wrote: > bdi is tied to the underlying block device, and helps for device > bandwidth specific throttling, dirty ratelimiting etc. Making it per > superblock will need duplicating the device specific throttling, ratelimiting > to superblock, which will be difficult. Yes, but my point is that compared to actually having a high performing writeback code that doesn't matter. What is the use case for actually having production workloads (vs just a root fs and EFI partition) on a single SSD or hard disk? > > 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. > > > > in this case with single wb thread multiple partitions/filesystems use the > same bdi, we fall back to base case, will that not help ? If you multiple file systems sharing a BDI, they can have different and potentially very different requirements and they can trivially get in the way. Or in other words we can't do anything remotely smart without fully having the file system in charge. 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 E20BBC8303C for ; Mon, 7 Jul 2025 14:28:34 +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=qcl3KEV5usAfoSd9CcEgn6Ssef+8WggPVeFEkz1b13g=; b=Rv7wJ7Ybo3juKCK8WtBdJuDcYW jvGJvYZVClmOAx5AbZb8XBEELSl/GsAV+NDB2yvicEeKbn1C1QdEGwpgn2qdC22StGg5PIOA6TU0Z Ibe7Ao9ZUdBD9J0WXBPDatxm+M32KCHpCdC41mrdjGko8R/vxQsuWUTfqalGEYsgYY6A=; Received: from [127.0.0.1] (helo=sfs-ml-1.v29.lw.sourceforge.com) by sfs-ml-1.v29.lw.sourceforge.com with esmtp (Exim 4.95) (envelope-from ) id 1uYmpd-0004xV-Kd; Mon, 07 Jul 2025 14:28:33 +0000 Received: from [172.30.29.66] (helo=mx.sourceforge.net) by sfs-ml-1.v29.lw.sourceforge.com with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1uYmpZ-0004xL-8t for linux-f2fs-devel@lists.sourceforge.net; Mon, 07 Jul 2025 14:28:29 +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=OI1L5YL5ipaEmWKqLKOkEhrGHjsWCxp6VA2Fygr0eUI=; b=jsLtWzvcgNXHlzqe/YRZvq0x5y 494vf6X5mm7Sn/K3u2Bq8o7SvOdjb45xgU8t+V17NKGajvi26dExD1xJ32kIzlrMCJhuqeA1CSQxB REnWu8RXYQ+m3IGvICqpm5iHnDY51GSbkIzdtmoMlqgKqPoyZIl3ZwKI6UMlFr0az85Y=; 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=OI1L5YL5ipaEmWKqLKOkEhrGHjsWCxp6VA2Fygr0eUI=; b=Kzrnaixf68eM+w8HrQRVov4c+9 O6FvRy/nyavj/bRrVSXpTq+K9BuppnQ1l1V/8i9mDcbGkRaegrVkXaTJC0DcMGu9CFnrw/pXVk/Ex 4iHdMNlaxNUgMDoxhQqsP3no0/xeXbwPR4Pj3I0qu49zXCDVbej/iyfmZskekxphYmX4=; 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 1uYmpY-00008V-Kt for linux-f2fs-devel@lists.sourceforge.net; Mon, 07 Jul 2025 14:28:29 +0000 Received: by verein.lst.de (Postfix, from userid 2407) id 6B34E68C7B; Mon, 7 Jul 2025 16:28:09 +0200 (CEST) Date: Mon, 7 Jul 2025 16:28:09 +0200 From: Christoph Hellwig To: Kundan Kumar Message-ID: <20250707142809.GA31459@lst.de> References: <20250529111504.89912-1-kundan.kumar@samsung.com> <20250529203708.9afe27783b218ad2d2babb0c@linux-foundation.org> <20250702184312.GC9991@frogsfrogsfrogs> <20250703130500.GA23864@lst.de> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) X-Headers-End: 1uYmpY-00008V-Kt 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, "Darrick J. Wong" , amir73il@gmail.com, david@fromorbit.com, gfs2@lists.linux.dev, linux-mm@kvack.org, clm@meta.com, Christoph Hellwig , dave@stgolabs.net, agruenba@redhat.com, miklos@szeredi.hu, Kundan Kumar , Matthew Wilcox , p.raghav@samsung.com, linux-nfs@vger.kernel.org, da.gomez@samsung.com, viro@zeniv.linux.org.uk, jaegeuk@kernel.org, Jens Axboe , Christian Brauner , linux-f2fs-devel@lists.sourceforge.net, mcgrof@kernel.org, anna@kernel.org, gost.dev@samsung.com, linux-fsdevel@vger.kernel.org, Andrew Morton , Trond Myklebust Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: linux-f2fs-devel-bounces@lists.sourceforge.net On Fri, Jul 04, 2025 at 12:32:51PM +0530, Kundan Kumar wrote: > bdi is tied to the underlying block device, and helps for device > bandwidth specific throttling, dirty ratelimiting etc. Making it per > superblock will need duplicating the device specific throttling, ratelimiting > to superblock, which will be difficult. Yes, but my point is that compared to actually having a high performing writeback code that doesn't matter. What is the use case for actually having production workloads (vs just a root fs and EFI partition) on a single SSD or hard disk? > > 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. > > > > in this case with single wb thread multiple partitions/filesystems use the > same bdi, we fall back to base case, will that not help ? If you multiple file systems sharing a BDI, they can have different and potentially very different requirements and they can trivially get in the way. Or in other words we can't do anything remotely smart without fully having the file system in charge. _______________________________________________ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel