Re: [rfc patch] optimize o_direct on block device

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On Nov 30, 2006, at 10:16 PM, Chen, Kenneth W wrote:

Zach Brown wrote on Thursday, November 30, 2006 1:45 PM
At that time, a patch was written for raw device to demonstrate that
large performance head room is achievable (at ~20% speedup for micro-
benchmark and ~2% for db transaction processing benchmark) with a
tight I/O submission processing loop.

Where exactly does the benefit come from?  icache misses?  "atomic"
ops leading to pipeline flushes?

It benefit from shorter path length. It takes much shorter time to process one I/O request, both in the submit and completion path. I always think in terms of how many instructions, or clock ticks does it take to convert user request into bio, submit it and in the return path, to process the bio call
back function and do the appropriate io completion (sync or async).

Sure.

What I'm hoping for is an understanding of what exactly the path is doing with those cycles. Do we have any more detailed measurements than, say, get_cycles() before and after the call?

Maybe it's time for me to have a good sit down with systemtap :)

- z
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux