* bdi forker
@ 2010-07-07 11:30 Artem Bityutskiy
2010-07-07 12:28 ` Artem Bityutskiy
2010-07-07 15:08 ` Christoph Hellwig
0 siblings, 2 replies; 3+ messages in thread
From: Artem Bityutskiy @ 2010-07-07 11:30 UTC (permalink / raw)
To: Jens Axboe, linux-fsdevel; +Cc: Christoph Hellwig
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
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: bdi forker
2010-07-07 11:30 bdi forker Artem Bityutskiy
@ 2010-07-07 12:28 ` Artem Bityutskiy
2010-07-07 15:08 ` Christoph Hellwig
1 sibling, 0 replies; 3+ messages in thread
From: Artem Bityutskiy @ 2010-07-07 12:28 UTC (permalink / raw)
To: Jens Axboe; +Cc: linux-fsdevel, Christoph Hellwig
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
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: bdi forker
2010-07-07 11:30 bdi forker Artem Bityutskiy
2010-07-07 12:28 ` Artem Bityutskiy
@ 2010-07-07 15:08 ` Christoph Hellwig
1 sibling, 0 replies; 3+ messages in thread
From: Christoph Hellwig @ 2010-07-07 15:08 UTC (permalink / raw)
To: Artem Bityutskiy; +Cc: Jens Axboe, linux-fsdevel, 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.
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2010-07-07 15:08 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-07-07 11:30 bdi forker Artem Bityutskiy
2010-07-07 12:28 ` Artem Bityutskiy
2010-07-07 15:08 ` Christoph Hellwig
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.