bdi forker

bdi forker

[Artem Bityutskiy]

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

Re: bdi forker

[Artem Bityutskiy]

On Wed, 2010-07-07 at 14:30 +0300, Artem Bityutskiy wrote:
> Hi Jens,
> 
> in your current design you have:

Fixing Jens' e-mail address. Jens, you should see the original e-mail in
linux-fsdevel.

-- 
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

Re: bdi forker

[Christoph Hellwig]

> 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.

They do.  I've actually implemented this and it simplifies the code a
lot.  But there's one big downside:  We now create a thread for every
block device, even if it's not used.  For a normal systems that's fine,
but on a system connected to a larger SAN this migh be quite a bit of
overhead.  Then again systems connected to a large SAN can usually deal
with the overhead.  I'm planning into just activating the thread if
a filesystems in mounted on the BDI, which should be just as a good as
the lazy startup/teardown.

I'll send out the preliminary series this week so that you can take a
look.