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 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. 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... -- Best Regards, Artem Bityutskiy (Артём Битюцкий) -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
