On 2010-07-08 16:21, Artem Bityutskiy wrote: > 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. That work would have to reside on the stack, and __mark_inode_dirty() block on the thread startup. We can't always do that. -- Jens Axboe -- 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
