From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ingo Molnar Subject: Re: [PATCH v2] kvm tools: Add QCOW level2 caching support Date: Thu, 2 Jun 2011 11:16:17 +0200 Message-ID: <20110602091617.GA9615@elte.hu> References: <1306956366-4634-1-git-send-email-prasadjoshi124@gmail.com> <20110602072850.GC2150@elte.hu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: kvm@vger.kernel.org, penberg@kernel.org, asias.hejun@gmail.com, gorcunov@gmail.com, levinsasha928@gmail.com, chaitanyakulkarni15@gmail.com, ashwini.kulkarni@gmail.com To: Prasad Joshi Return-path: Received: from mx2.mail.elte.hu ([157.181.151.9]:36490 "EHLO mx2.mail.elte.hu" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932177Ab1FBJQ1 (ORCPT ); Thu, 2 Jun 2011 05:16:27 -0400 Content-Disposition: inline In-Reply-To: <20110602072850.GC2150@elte.hu> Sender: kvm-owner@vger.kernel.org List-ID: * Ingo Molnar wrote: > 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. Another risk that the current situation carries in itself, beyond making it more difficult to measure improvements, is that based on a "bad" Bonnie outlier or artifact you might throw away a perfectly good change accidentally! So whenever you think you are fighting noise you need to improve your measurements, as entropy is a pretty tough opponent to beat. Thanks, Ingo