Mathieu Desnoyers wrote: >> remember that we have seen and discussed something like this before, >> it's still a puzzle to me... >> >> > I do wonder about that performance _increase_ with blktrace enabled. I > > Interesting question indeed. > > In those tests, when blktrace is running, are the relay buffers only > written to or they are also read ? >
blktrace (the utility) was running too - so the relay buffere /were/ being read and stored out to disk elsewhere. > Running the tests without consuming the buffers (in overwrite mode) > would tell us more about the nature of the disturbance causing the > performance increase. > I'd have to write a utility to enable the traces, but then not read. Let me think about that. > Also, a kernel trace could help us understand more thoroughly what is > happening there.. is it caused by the scheduler ? memory allocation ? > data cache alignment ? > Yep - when I get some time, I'll look into that. [Clearly not a gating issue for marker support...] > I would suggest that you try aligning the block layer data structures > accessed by blktrace on L2 cacheline size and compare the results (when > blktrace is disabled). > Again, when I get some time! :-) Alan - 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/
