Re: [PATCH v7.1] block: Coordinate flush requests

[Shaohua Li]

2011/1/16 Tejun Heo <tj@xxxxxxxxxx>:
> Hello,
>
> On Fri, Jan 14, 2011 at 09:00:22AM +0800, Shaohua Li wrote:
>> it appears we can easily implement this in blk_do_flush, I had
>> something at my hand too, passed test but no data yet.
>
>> Task1: ...FS.....C
>> Task2: ....F......S...C
>> Task3: ......F.........S..C
>> F means a flush is queued, S means a flush is dispatched, C means the flush
>> is completed. In above, when Task2's flush is completed, we actually can
>> make Task3 flush complete, as Task2's flush is dispatched after Task3's flush
>> is queued. With the same reason, we can't merge Task2 and Task3's flush with
>> Task1's.
>
> I think this is the correct direction but we can take it further.  The
> only thing block layer has to guarantee is (ignoring FUA support),
>
> * If the flush request is empty, at least one flush is executed upon
>  its completion.
>
> * If the flush request is not empty, the payload is written only after
>  a preceding flush and follwed by another flush if requested.
>
> So, if we can combine N flushes with or without data,
>
>  PREFLUSH -> N flush data payloads -> POSTFLUSH
This makes sense. would it possible N flush data payloads delay the
first request?

> The following is something I hacked past few hours.  I just made it
> compile so it's definitely horridly broken.  Please don't try to even
> test it, but it should still give an idea about the direction.  I'll
> try to finish this early next week.
I'm looking forward to seeing it.

Thanks,
Shaohua
--
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/