[lkml]   [2011]   [Jan]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH v7.1] block: Coordinate flush requests
2011/1/16 Tejun Heo <>:
> 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.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2011-01-18 02:15    [W:0.119 / U:2.368 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site