From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christoph Hellwig Subject: Re: [PATCH 1/3] writeback: simplify the write back thread queue Date: Sun, 20 Jun 2010 11:00:06 +0200 Message-ID: <20100620090006.GA14702@lst.de> References: <20100619210756.GA29875@lst.de> <1277023258.2503.27.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Christoph Hellwig , axboe@kernel.dk, linux-fsdevel@vger.kernel.org To: Artem Bityutskiy Return-path: Received: from verein.lst.de ([213.95.11.210]:41330 "EHLO verein.lst.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755906Ab0FTJAJ (ORCPT ); Sun, 20 Jun 2010 05:00:09 -0400 Content-Disposition: inline In-Reply-To: <1277023258.2503.27.camel@localhost.localdomain> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Sun, Jun 20, 2010 at 11:40:58AM +0300, Artem Bityutskiy wrote: > Christoph, thanks for simplifying this. I wonder also, why do we need > the bdi_pending_list - for me it looks redundant. > > Also, do we need the forker task? It hurts because it wakes up every 5 > sec jut to check whether it has to fork something and to waste the > battery energy. Do we really need to bdi threads to kill themselves > after 5 minutes of inactivity? I don't like the design very much either. I think the problem is that we currently don't have an interface to tell whether a bdi is actually used for a filesystem. We only need the flusher thread any filesystem is using a bdi currently. I've started looking a this, but it's not that easy. First I need to sort out the current bdi_init/register/ unregister/destroy interface which has grown organicly and currenly isn't exacly symmetric. After that I can look into a new interface to start/stop the thread on an otherwise fully set up bdi, which should allow getting rid of the forker and it's complications.