From mboxrd@z Thu Jan  1 00:00:00 1970
From: Ingo Molnar <mingo@elte.hu>
Subject: Re: RCU red-black tree (was: Re: [PATCH 4/6] kvm tools: Add rwlock
 wrapper)
Date: Tue, 31 May 2011 21:31:37 +0200
Message-ID: <20110531193137.GA24186@elte.hu>
References: <20110530025414.GA25865@Krystal>
 <1306735631.14564.34.camel@lappy>
 <20110530173844.GA13361@Krystal>
 <1306777969.15912.3.camel@lappy>
 <20110530185757.GA13903@Krystal>
 <1306847114.25406.9.camel@lappy>
 <20110531130923.GA13888@elte.hu>
 <1306848006.25406.11.camel@lappy>
 <20110531152539.GA22353@elte.hu>
 <BANLkTin-VoG4HkqFfQ3eS2Ci4SXdd0USDQ@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: Sasha Levin <levinsasha928@gmail.com>,
	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
	Pekka Enberg <penberg@kernel.org>, Avi Kivity <avi@redhat.com>,
	john@jfloren.net, kvm@vger.kernel.org, asias.hejun@gmail.com,
	gorcunov@gmail.com,
	"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
	Phil Howard <csbetterthanjava@gmail.com>, rp@svcs.cs.pdx.edu
To: Prasad Joshi <prasadjoshi124@gmail.com>
Return-path: <kvm-owner@vger.kernel.org>
Received: from mx2.mail.elte.hu ([157.181.151.9]:42297 "EHLO mx2.mail.elte.hu"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1754013Ab1EaTb7 (ORCPT <rfc822;kvm@vger.kernel.org>);
	Tue, 31 May 2011 15:31:59 -0400
Content-Disposition: inline
In-Reply-To: <BANLkTin-VoG4HkqFfQ3eS2Ci4SXdd0USDQ@mail.gmail.com>
Sender: kvm-owner@vger.kernel.org
List-ID: <kvm.vger.kernel.org>


* Prasad Joshi <prasadjoshi124@gmail.com> wrote:

> May be the DD of 1G file was a wrong test to calculate the 
> performance. Sasha had asked me to run boniee++ for performance 
> numbers. [...]

It's difficult to test IO performance. One way to 'stabilize' such 
measurements would be to create a 'make test io' variant, which 
builds not just a simple 'Hello World!' but also an IO performance 
benchmark.

The advantage of such an approach (beyond the fun of writing it) 
would be that it's executed at a very predictable point in the bootup 
sequence, so if you keep the whole disk image in ramdisk (in 
/dev/shm/ for example) then it would allow very precise measurements 
that converge very quickly with very little noise.

Thanks,

	Ingo