bdi forker

[Artem Bityutskiy <dedekind1@gmail.com>]

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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html