On Mon, Jul 06 2009, Artem Bityutskiy wrote: > Jens Axboe wrote: >> +/* >> + * kupdated() used to do this. We cannot do it from the bdi_forker_task() >> + * or we risk deadlocking on ->s_umount. The longer term solution would be >> + * to implement sync_supers_bdi() or similar and simply do it from the >> + * bdi writeback tasks individually. >> + */ >> +static int bdi_sync_supers(void *unused) >> +{ >> + set_user_nice(current, 0); >> + >> + while (!kthread_should_stop()) { >> + set_current_state(TASK_INTERRUPTIBLE); >> + schedule(); >> + >> + /* >> + * Do this periodically, like kupdated() did before. >> + */ >> + sync_supers(); >> + } >> + >> + return 0; > > ATM we have one timer for both data and super-block synchronization. > With per-bdi write-back we have: > > 1. one timer for super blocks > 2. many per-bdi timers for data (schedule_timeout() is essentially > using timers). That is correct. Note that these exit when they have been idle for a while, for embedded and such you could make it more aggressive by exiting quicker. The sync_supers should be directly fixable by your sb_dirty() stuff. So I don't think it's a huge change from what we currently have. > This is not nice, because each timer is an additional source of > power-savings killers. I mean, it is more power management (PM) > friendly to have less timers and disturb CPU less, make CPU wake > up from retention less frequently. > > I do not challange the per-bdi idea at all, but is it possible to > think about a more PM-friendly desing and have one source of > periodic write-back, not many. I mean, could there be one timer > which periodically syncs supers and wakes up the BDI write-back > tasks? You could replace the schedule_timeout() by a schedule(), and instead have a single timer running that would scan the bdi_list and issue the kupdated() timed writeback that is the reason it uses schedule_timeout() now. Explicitly issued work will manually wake up the per-bdi thread(s). That single timer could easily handle waking up bdi_sync_supers() as well. -- 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