From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dave Chinner Subject: Re: [PATCH 0/4 RESEND] writeback: Dirty list handling changes Date: Sat, 17 May 2014 08:42:44 +1000 Message-ID: <20140516224244.GH26353@dastard> References: <1400168517-3565-1-git-send-email-jack@suse.cz> <20140515235514.GH5421@dastard> <20140516004754.GJ5421@dastard> <20140516092720.GA27594@infradead.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Jan Kara , linux-fsdevel@vger.kernel.org, Wu Fengguang , Andrew Morton To: Christoph Hellwig Return-path: Received: from ipmail06.adl2.internode.on.net ([150.101.137.129]:60295 "EHLO ipmail06.adl2.internode.on.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753687AbaEPWmr (ORCPT ); Fri, 16 May 2014 18:42:47 -0400 Content-Disposition: inline In-Reply-To: <20140516092720.GA27594@infradead.org> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Fri, May 16, 2014 at 02:27:20AM -0700, Christoph Hellwig wrote: > > Seems to me that this problem has been solved elswhere in the > > kernel, like for tracking of timers to expire on a given jiffie > > (tvec, tvec_base, timer_lists). Perhaps we should be looking to move > > to a set of time based lists for efficiently tracking what inodes > > should be written back at a given background writeback interval > > rather than trying to keep everything on the one list. > > It's also pretty similar to the mru cache we use for filesystems in XFS, > except that we'd start writeback instead of deleting items. The whole > bucket scheme there should also help with I/O batching. *nod* I thought about that, but then though that an example from a core subsystem would be better ;) Cheers, Dave. -- Dave Chinner david@fromorbit.com