From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JAYPV-0004A5-NP for qemu-devel@nongnu.org; Thu, 03 Jan 2008 17:19:33 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JAYPU-00048c-NU for qemu-devel@nongnu.org; Thu, 03 Jan 2008 17:19:33 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JAYPU-00048K-Gs for qemu-devel@nongnu.org; Thu, 03 Jan 2008 17:19:32 -0500 Received: from nz-out-0506.google.com ([64.233.162.228]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1JAYPU-0007op-6s for qemu-devel@nongnu.org; Thu, 03 Jan 2008 17:19:32 -0500 Received: by nz-out-0506.google.com with SMTP id f1so5049026nzc.37 for ; Thu, 03 Jan 2008 14:19:31 -0800 (PST) Message-ID: <761ea48b0801031419w7db42f83o7030d7c3e740512e@mail.gmail.com> Date: Thu, 3 Jan 2008 23:19:29 +0100 From: "Laurent Desnogues" Subject: Re: [Qemu-devel] performance monitor In-Reply-To: <200801032311.24715.clemens.kol@gmx.at> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200801032136.27558.clemens.kol@gmx.at> <200801032238.03458.clemens.kol@gmx.at> <200801032207.08448.paul@codesourcery.com> <200801032311.24715.clemens.kol@gmx.at> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org On Jan 3, 2008 11:11 PM, Clemens Kolbitsch wrote: > > Well, the measuring I had in mind partly concentrats on TLB misses, page > faults, etc. (in addition to the cycle measuring). guess i'll have to > implement something for myself in qemu :-/ There's something not clear here: do you want to measure your kernel changes or do you want to profile Qemu? As Paul clearly explained you can't do both :) If you want to measure kernel performance oprofile is probably worth looking at. But you will need the real hardware. Another option, though much more intrusive, would be to add explicit performance counters in places you need to look at (this method can be applied to both Qemu too). And to say it again: nobody can expect to measure OS performance on a simulator, unless the simulator is directly derived from the HDL code written by designers. At least I would never trust such a result ;) Laurent