sorry for late responce. I wonder why I and Wu don't contain Cc list in this thread. > Hisashi Hifumi wrote: > > At 09:36 09/06/01, Andrew Morton wrote: > >> On Fri, 29 May 2009 14:35:55 +0900 Hisashi Hifumi > >> <hifumi.hisashi@xxxxxxxxxxxxx> wrote: > >> > >>> I added blk_run_backing_dev on page_cache_async_readahead > >>> so readahead I/O is unpluged to improve throughput on > >>> especially RAID environment. > >> I skipped the last version of this because KOSAKI Motohiro > >> <kosaki.motohiro@xxxxxxxxxxxxxx> said "Please attach blktrace analysis ;)". > >> > >> I'm not sure why he asked for that, but he's a smart chap and > >> presumably had his reasons. > >> > >> If you think that such an analysis is unneeded, or isn't worth the time > >> to generate then please tell us that. But please don't just ignore the > >> request! > > > > Hi Andrew. > > > > Sorry for this. > > > > I did not ignore KOSAKI Motohiro's request. > > I've got blktrace output for both with and without the patch, > > but I just did not clarify the reason for throuput improvement > > from this result. > > > > I do not notice any difference except around unplug behavior by dd. > > Comments? > > Pardon my ignorance on the global issues concerning the patch, but > specifically looking at the traces generated by blktrace leads one to > also note that the patched version may generate inefficiencies in other > places in the kernel by reducing the merging going on. In the unpatched > version it looks like (generally) that two incoming bio's are able to be > merged to generate a single I/O request. In the patched version - > because of the quicker unplug(?) - no such merging is going on. This > leads to more work lower in the stack (twice as many I/O operations > being managed), perhaps increased interrupts & handling &c. [This may be > acceptable if the goal is to decrease latencies on a per-bio basis...] > > Do you have a place where the raw blktrace data can be retrieved for > more in-depth analysis? I think your comment is really adequate. In another thread, Wu Fengguang pointed out the same issue. I and Wu also wait his analysis. Thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
