Hello Tejun,
I'm writing to you since you're signed on the blk-flush.c file, hoping
you could answer a flush-related question for me. Please excuse me if
you're not the right person to address this to.
I've been looking into the flush implementation, trying to understand
how it works. FLUSH command can be used for two purposes:
1. Flush the data to the non-volatile memory from the card cache
2. Keep an order of requests: req_A.... req_D, FLUSH, req_C...req_X
Unfortunately I don't understand how the second purpose of FLUSH is
implemented. If to simplify the question, let take for example a card
that doesn't implement a writeback cache (doesn't support FLUSH/FUA) and
the following example:
The application inserts req_A...req_D to the block layer (and the
scheduler) and issues req_FLUSH that contains data. What is expected in
this situation is that req_A..req_D will be written to the non-volatile
memory before req_FLUSH.
According to the code at blk_insert_flush() the req_FLUSH request will
be marked as SOFTBARRIER and added to the tail of the dispatch queue.
But what guaranties that by the time it's added to the dispatch queue
req_A..req_D have been dispatched as well? It's possible that they are
still in scheduler and will be dispatched only after req_FLUSH is
completed...
One possible solution to this is if the application waits to get a
completion callback on req_A..req_D before issuing the req_FLUSH. Is
this indeed the case? I didn't find any documentation on it on the web.
Thanks,
Tanya Brokhman
--
QUALCOMM ISRAEL, on behalf of Qualcomm Innovation Center, Inc. is a
member of Code Aurora Forum, hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
