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 21:43:22 +0300 Message-ID: <1278614602.7365.8.camel@localhost.localdomain> References: <20100707225242.GA28802@lst.de> <4C35C292.9020507@kernel.dk> <1278598877.20321.34.camel@localhost> <4C35E7D5.8020809@kernel.dk> <1278602632.9953.4.camel@localhost> <4C360998.9040609@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 mail-fx0-f46.google.com ([209.85.161.46]:33053 "EHLO mail-fx0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758293Ab0GHSn1 (ORCPT ); Thu, 8 Jul 2010 14:43:27 -0400 Received: by fxm14 with SMTP id 14so603214fxm.19 for ; Thu, 08 Jul 2010 11:43:25 -0700 (PDT) In-Reply-To: <4C360998.9040609@kernel.dk> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Thu, 2010-07-08 at 19:23 +0200, Jens Axboe wrote: > On 08/07/10 17.23, Artem Bityutskiy wrote: > > On Thu, 2010-07-08 at 16:59 +0200, Jens Axboe wrote: > >>> 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 d= irty > >>> (__mark_inode_dirty()) or a bdi work is queued (bdi_queue_work())= ? If we > >>> do this, then the tasks can also die by the 5min timeout, and wil= l be > >>> forked again when dirt/bdi works arrives? > >>> > >>> I guess it is a bit challenging to start a task in __mark_inode_d= irty(), > >>> whis is supposed to be fast and non-sleeping, but we can just sub= mit a > >>> work which will start the task. > >> > >> That work would have to reside on the stack, and __mark_inode_dirt= y() > >> block on the thread startup. We can't always do that. > >=20 > > We can have a pre-defined bdi->wb->task_start_work or something lik= e > > that. >=20 > Yeah, that would work. Hmm, was thinking about this while driving home - the forker approach has a good resilience property - if it cannot fork - it'll do the stuff itself. I have a feeling that if something like this to be implemented with the approach I suggested, we'll end up with similar level of complexity that we wanted to get rid of... =20 --=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