From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jens Axboe Subject: Re: [PATCH, RFC] simplify writeback thread creation Date: Thu, 08 Jul 2010 19:23:36 +0200 Message-ID: <4C360998.9040609@kernel.dk> References: <20100707225242.GA28802@lst.de> <4C35C292.9020507@kernel.dk> <1278598877.20321.34.camel@localhost> <4C35E7D5.8020809@kernel.dk> <1278602632.9953.4.camel@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Christoph Hellwig , linux-fsdevel@vger.kernel.org To: dedekind1@gmail.com Return-path: Received: from 0122700014.0.fullrate.dk ([95.166.99.235]:42241 "EHLO kernel.dk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758123Ab0GHRXh (ORCPT ); Thu, 8 Jul 2010 13:23:37 -0400 In-Reply-To: <1278602632.9953.4.camel@localhost> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: 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 dirty >>> (__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 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. >> >> That work would have to reside on the stack, and __mark_inode_dirty() >> block on the thread startup. We can't always do that. > > We can have a pre-defined bdi->wb->task_start_work or something like > that. Yeah, that would work. -- Jens Axboe