Re: [RESEND] [PATCH] readahead:add blk_run_backing_dev
From: Vladislav Bolkhovitin
Date: Tue Jul 14 2009 - 14:53:06 EST
Wu Fengguang, on 07/13/2009 04:36 PM wrote:
Test done with XFS on both the target and the initiator. This confirms
your findings, using files instead of block devices is faster, but
only when using the io_context patch.
It shows that the one really matters is the io_context patch,
even when context readahead is running. I guess what happened
in the tests are:
- without readahead (or readahead algorithm failed to do proper
sequential readaheads), the SCST processes will be submitting
small but close to each other IOs. CFQ relies on the io_context
patch to prevent unnecessary idling.
- with proper readahead, the SCST processes will also be submitting
close readahead IOs. For example, one file's 100-102MB pages is
readahead by process A, while its 102-104MB pages may be
readahead by process B. In this case CFQ will also idle waiting
for process A to submit the next IO, but in fact that IO is being
submitted by process B. So the io_context patch is still necessary
even when context readahead is working fine. I guess context
readahead do have the added value of possibly enlarging the IO size
(however this benchmark seems to not very sensitive to IO size).
Looks like the truth. Although with 2MB RA I expect CFQ to do idling >10
times less, which should bring bigger improvement than few %%.
For how long CFQ idles? For HZ/125, i.e. 8 ms with HZ 250?
Thanks,
Fengguang
--
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/