Re: [RFC][PATCH 2/7] writeback: fix queue_io() ordering
From: Wu Fengguang
Date: Wed Sep 09 2009 - 21:26:42 EST
On Wed, Sep 09, 2009 at 11:53:30PM +0800, Jan Kara wrote:
>
On Wed 09-09-09 22:51:43, Wu Fengguang wrote:
>
> This was not a bug, since b_io is empty for kupdate writeback.
>
> The next patch will do requeue_io() for non-kupdate writeback,
>
> so let's fix it.
>
But doesn't this patch also need your "anti-starvation" patch?
Honza, can you show me that patch?
>
Looking into the code, we put inode to b_more_io when nr_to_write
>
drops to zero and this way we'd just start writing it again
>
in the next round...
I'm confused. It's OK to start it in next round. Starvation can
occur if we start it immediately in the next writeback_inodes()
invocation. How can that happen with this patch?
Thanks,
Fengguang
>
Honza
>
>
>
> CC: Dave Chinner <david@xxxxxxxxxxxxx>
>
> Cc: Martin Bligh <mbligh@xxxxxxxxxx>
>
> Cc: Michael Rubin <mrubin@xxxxxxxxxx>
>
> Cc: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
>
> Signed-off-by: Fengguang Wu <wfg@xxxxxxxxxxxxxxxx>
>
> ---
>
> fs/fs-writeback.c | 7 +++++--
>
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
>
>
> --- linux.orig/fs/fs-writeback.c 2009年09月09日 21:41:14.000000000 +0800
>
> +++ linux/fs/fs-writeback.c 2009年09月09日 21:45:15.000000000 +0800
>
> @@ -313,11 +313,14 @@ static void move_expired_inodes(struct l
>
> }
>
>
>
> /*
>
> - * Queue all expired dirty inodes for io, eldest first.
>
> + * Queue all expired dirty inodes for io, eldest first:
>
> + * (newly dirtied) => b_dirty inodes
>
> + * => b_more_io inodes
>
> + * => remaining inodes in b_io => (dequeue for sync)
>
> */
>
> static void queue_io(struct bdi_writeback *wb, unsigned long *older_than_this)
>
> {
>
> - list_splice_init(&wb->b_more_io, wb->b_io.prev);
>
> + list_splice_init(&wb->b_more_io, &wb->b_io);
>
> move_expired_inodes(&wb->b_dirty, &wb->b_io, older_than_this);
>
> }
>
>
>
>
>
> --
>
>
>
--
>
Jan Kara <jack@xxxxxxx>
>
SUSE Labs, CR
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
http://vger.kernel.org/majordomo-info.html
Please read the FAQ at
http://www.tux.org/lkml/