Re: [PATCH, RFC] simplify writeback thread creation

[Artem Bityutskiy <dedekind1@gmail.com>]

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 is
> > dirty any dirty data on the BDI, and it lazy exists when it's been
> > unused for some time.
> > 
> > This leads to some very complex code, and the need to keep a forker
> > thread around.
> > 
> > This patch removes all this code and simply creates the thread as part
> > 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 ressources.
> > 
> > If the overhead is still considered too much I can look into starting
> > the thread explicitly instead of as part of the bdi registration, but
> > that will require a bit of code complexity, too.
> 
> I'm pretty sure this will come back to bite us in the ass... If we are
> 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 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.

-- 
Best Regards,
Artem Bityutskiy (Артём Битюцкий)

--
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