Hi Jens,
in your current design you have:
1. bdi_forker_task() which wakes up every 5 seconds just to check
whether it has to fork a per-bdi thread or not.
2. per-bdi threads which wake up when there are bdi works or every 5
seconds to do kupdated style write-back. These threads also die after 5
minutes of "inactivity", and will be forked by the bdi_forker_task() if
needed.
This is bad from the power management POW, and I'd like to fix this. If
you have any ideas/directions for me, please, share.
I was looking at the code and and found it to bee more complex that it
has to be. I'd suggest to:
1. Stop exiting per-bdi flushers after 5 minutes of inactivity.
2. Kill the forker thread and make the default bdi us the same flusher
thread as every other bdi uses.
This will simplify many things, I believe. Various lists and locks and
will go away, the code will become more readable.
Also, I noticed the following code fragment:
static void bdi_queue_work(struct backing_dev_info *bdi,
struct wb_writeback_work *work)
{
spin_lock(&bdi->wb_lock);
list_add_tail(&work->list, &bdi->work_list);
spin_unlock(&bdi->wb_lock);
/*
* If the default thread isn't there, make sure we add it. When
* it gets created and wakes up, we'll run this work.
*/
if (unlikely(!bdi->wb.task)) {
wake_up_process(default_backing_dev_info.wb.task);
} else {
struct bdi_writeback *wb = &bdi->wb;
if (wb->task)
wake_up_process(wb->task);
}
}
What prevents the flusher task from deciding to commit suicide, set
wb->task to NULL, and make this code to do wake_up_process(NULL)?
--
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
