From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Phillips Subject: Re: [PATCH 14/14] writeback: Per-sb dirty tracking Date: Thu, 31 Jul 2014 22:14:38 -0700 Message-ID: <53DB223E.6020800@phunq.net> References: <1406844053-25982-1-git-send-email-jack@suse.cz> <1406844053-25982-15-git-send-email-jack@suse.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: OGAWA Hirofumi , Wu Fengguang To: Jan Kara , linux-fsdevel@vger.kernel.org Return-path: Received: from mail.phunq.net ([184.71.0.62]:55135 "EHLO starbase.phunq.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752946AbaHAFzs (ORCPT ); Fri, 1 Aug 2014 01:55:48 -0400 In-Reply-To: <1406844053-25982-15-git-send-email-jack@suse.cz> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On 07/31/2014 03:00 PM, Jan Kara wrote: > Switch inode dirty tracking lists to be per superblock instead of per > bdi. This is a major step towards filesystems being able to do their > own dirty tracking... I'll say :) > ...and selection of inodes for writeback if they desire > so (e.g. because they journal or COW data and need to writeback inodes > & pages in a specific order unknown to generic writeback code). Well, I don't see an actual API here. I suppose that is intentional. Shall we just roll one, or do you have some suggestions? Obviously, this groundwork is just what Tux3 wants, and if I got the sense of the previous discussion correctly, XFS could be able to benefit from it too, not to mention others. So... is this patch set something we should be testing right now, or is it just for comment, or already on its way upstream, or other? Did you get prelimary performance data? Regards, Daniel > Per superblock dirty lists also make selecting inodes for writeback > somewhat simpler because we don't have to search for inodes from a > particular superblock for some kinds of writeback (OTOH we pay for this > by having to iterate through superblocks for all-bdi type of writeback) > and this simplification will allow for an easier switch to a better > scaling data structure for dirty inodes. Regards, Daniel