On Thu, Jun 2, 2011 at 8:28 AM, Ingo Molnar <mingo@xxxxxxx> wrote: > > * Prasad Joshi <prasadjoshi124@xxxxxxxxx> wrote: > >> Summary of performance numbers >> ============================== >> There is not much difference with sequential character operations are >> performed, the code with caching performed better by small margin. The caching >> code performance raised by 12% with sequential block output and dropped by >> 0.5% with sequential block input. The caching code also suffered with >> Random seeks and performed badly by 12%. The performance numbers drastically >> improved with sequential creates (62%) and delete operations (30%). > > Looking at the numbers i think it's pretty clear that from this point > on the quality of IO tests should be improved: Bonnie is too noisy > and does not cut it anymore for finer enhancements. > > To make measurements easier you could also do a simple trick: put > *all* of the disk image into /dev/shm and add a command-line debug > option that add a fixed-amount udelay(1000) call every time the code > reads from the disk image. > > This introduces a ~1msec delay and thus simulates IO, but the delays > are *constant* [make sure you use a high-res timers kernel], so they > do not result in nearly as much measurement noise as real block IO > does. > > The IO delays will still be there, so any caching advantages (and CPU > overhead reductions) will be measurable very clearly. > > This way you are basically 'emulating' a real disk drive but you will > emulate uniform latencies, which makes measurements a lot more > reliable - while still relevant to the end result. > > So if under such a measurement model you can prove an improvement > with a patch, that improvement will be there with real disks as well > - just harder to prove. > > Wanna try this? I really think you are hitting the limits of your > current measurement methodology and you will be wasting time running > more measurements instead of saving time doing more intelligent > measurements ;-) > Thanks Ingo, will try this method. I am not sure how to induce the delay you mentioned. I could vaguely remember you suggesting something similar few days back. Let me see if I can find out the correct arguments to use this delay, otherwise will post a query. Thanks and Regards, Prasad > Thanks, > > Ingo > -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
