From mboxrd@z Thu Jan 1 00:00:00 1970 From: Artem Bityutskiy Subject: Re: [PATCH, RFC] simplify writeback thread creation Date: Thu, 08 Jul 2010 17:21:17 +0300 Message-ID: <1278598877.20321.34.camel@localhost> References: <20100707225242.GA28802@lst.de> <4C35C292.9020507@kernel.dk> Reply-To: dedekind1@gmail.com Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Christoph Hellwig , linux-fsdevel@vger.kernel.org To: Jens Axboe Return-path: Received: from smtp.nokia.com ([192.100.122.230]:25884 "EHLO mgw-mx03.nokia.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751749Ab0GHO0B (ORCPT ); Thu, 8 Jul 2010 10:26:01 -0400 In-Reply-To: <4C35C292.9020507@kernel.dk> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Thu, 2010-07-08 at 14:20 +0200, Jens Axboe wrote: > On 2010-07-08 00:52, Christoph Hellwig wrote: > > Currently the per-bdi writeback thread is only created when there i= s > > dirty any dirty data on the BDI, and it lazy exists when it's been > > unused for some time. > >=20 > > This leads to some very complex code, and the need to keep a forker > > thread around. > >=20 > > This patch removes all this code and simply creates the thread as p= art > > of the bdi registration. The downside is that we use up ressoures > > for possible unused devices, although that overhead is rather low, > > with 8k kernel stack size on x86 and few other, even smaller ressou= rces. > >=20 > > If the overhead is still considered too much I can look into starti= ng > > the thread explicitly instead of as part of the bdi registration, b= ut > > that will require a bit of code complexity, too. >=20 > I'm pretty sure this will come back to bite us in the ass... If we ar= e > going to change the lazy create/exit setup, I would greatly prefer > doing it at fs mount time (or something to that effect). How about not starting any thread at all at the bdi registration time, and start a bdi thread only when something for this bdi becomes dirty (__mark_inode_dirty()) or a bdi work is queued (bdi_queue_work())? If w= e do this, then the tasks can also die by the 5min timeout, and will be forked again when dirt/bdi works arrives? I guess it is a bit challenging to start a task in __mark_inode_dirty()= , whis is supposed to be fast and non-sleeping, but we can just submit a work which will start the task. --=20 Best Regards, Artem Bityutskiy (=D0=90=D1=80=D1=82=D1=91=D0=BC =D0=91=D0=B8=D1=82=D1=8E= =D1=86=D0=BA=D0=B8=D0=B9) -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel= " in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html