From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1EMmF3-0006a3-AO for qemu-devel@nongnu.org; Tue, 04 Oct 2005 08:49:57 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1EMmF2-0006Zg-5r for qemu-devel@nongnu.org; Tue, 04 Oct 2005 08:49:56 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EMmE5-0005rp-N3 for qemu-devel@nongnu.org; Tue, 04 Oct 2005 08:48:57 -0400 Received: from [195.184.98.160] (helo=virtualhost.dk) by monty-python.gnu.org with esmtp (TLS-1.0:DHE_RSA_3DES_EDE_CBC_SHA:24) (Exim 4.34) id 1EMloK-0000qN-SE for qemu-devel@nongnu.org; Tue, 04 Oct 2005 08:22:21 -0400 Date: Tue, 4 Oct 2005 14:22:55 +0200 From: Jens Axboe Subject: Re: [Qemu-devel] [patch] non-blocking disk IO Message-ID: <20051004122254.GO3511@suse.de> References: <4340D479.7030301@stanfordalumni.org> <434100A3.5030104@dblab.ece.ntua.gr> <46d6db660510030558y3413a698ra74d5a270de58bf2@mail.gmail.com> <43422C99.2010300@stanfordalumni.org> <434242DE.40906@dblab.ece.ntua.gr> <46d6db660510040235i547ea37aw33965dbe77c0a390@mail.gmail.com> <46d6db660510040419p475ed971w3a452c0cebbfa13f@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46d6db660510040419p475ed971w3a452c0cebbfa13f@mail.gmail.com> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Christian MICHON , qemu-devel@nongnu.org On Tue, Oct 04 2005, Christian MICHON wrote: > hmmm.... > > the static binary crashes, the one with ptreadGC2.dll is ok. > > What I tried to measure, on windows host, kqemu-0.7.2 > loaded, was: > (1) tar -jxf linux-2.6.10.tar.bz2 > (2) make allnoconfig; make > > I confirm ~18% speed improvement in case (1), but no change > more or less for case (2). I believe maybe someone with a > windows host SMP could get different figures. If so, please > update these accordingly and let the list know. > > Indeed, threading on a busy single CPU doesn't make it faster. That's not quite true. The io thread basically takes no real CPU, but it often has to wait for io to become available. So even (especially!) for a single cpu system, you definitely want to make sure that blocking io doesn't eat away cpu cycles from a cpu bound case like the compile. If you did the kernel compile with a hot disk cache, I'm not surprised you're not seeing a performance benefit of the non-blocking io patch. Even for a cold cache compile it will generally be cpu bound. -- Jens Axboe