From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:34858) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bCnHm-0003EV-Nm for qemu-devel@nongnu.org; Tue, 14 Jun 2016 08:17:39 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bCnHi-0002st-H3 for qemu-devel@nongnu.org; Tue, 14 Jun 2016 08:17:37 -0400 Received: from roura.ac.upc.edu ([147.83.33.10]:36205 helo=roura.ac.upc.es) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bCnHi-0002sh-4a for qemu-devel@nongnu.org; Tue, 14 Jun 2016 08:17:34 -0400 From: =?utf-8?Q?Llu=C3=ADs_Vilanova?= References: <145641255678.30097.2919142707547689749.stgit@localhost> <145641258612.30097.7127731954660712163.stgit@localhost> <30b46b30-fbc0-31a4-6210-657b205c121f@redhat.com> <87lh29cmip.fsf@fimbulvetr.bsc.es> <878ty9xctp.fsf@fimbulvetr.bsc.es> <20160614083922.GA25111@stefanha-x1.localdomain> Date: Tue, 14 Jun 2016 14:17:23 +0200 In-Reply-To: (Paolo Bonzini's message of "Tue, 14 Jun 2016 11:13:06 +0200") Message-ID: <87k2hsrmlo.fsf@fimbulvetr.bsc.es> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH 4/6] trace: Add per-vCPU tracing states for events with the 'vcpu' property List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: Stefan Hajnoczi , qemu-devel@nongnu.org, Blue Swirl , Riku Voipio , Eduardo Habkost , Andreas =?utf-8?Q?F=C3=A4rber?= Paolo Bonzini writes: > On 14/06/2016 10:39, Stefan Hajnoczi wrote: >> On Mon, Jun 13, 2016 at 06:39:46PM +0200, Llu=C3=ADs Vilanova wrote: >>> Paolo Bonzini writes: >>>=20 >>>> On 13/06/2016 14:15, Llu=C3=ADs Vilanova wrote: >>>>>> That said, I am skeptical about the benefit of the interfaces you are >>>>>> adding. They add a lot of complication and overhead (especially >>>>>> regarding the memory/cache overhead of the dstate array) without a c= lear >>>>>> use case, in my opinion; all the processing you do at run-time is ju= st >>>>>> as well suited for later filtering. >>>>>=20 >>>>> This should make tracing faster on the future with multi-threaded TCG= , as well >>>>> as trace files much smaller if you're tracing something like memory >>>>> accesses. Also, bear in mind this series was split from a much larger= one for >>>>> simplicity. The follow-up one provides much larger performance benefi= ts by >>>>> avoiding the generation of TCG code to call the tracing backend when = a vCPU is >>>>> not traced. >>>=20 >>>> This still assumes that tracing only some VCPUs is a common use case. >>>> Is it?... >>>=20 >>> I use it for code profiling by sampling across vCPUs, or only on vCPUs = I know >>> run processes of my interest. The profiles can then be used for analyzi= ng the >>> application/system behaviour. >>>=20 >>> Also, with the fast-path checks already in place ('trace_events_enabled= _count'), >>> performance when not tracing should never be worse with this series. >>>=20 >>> If this feature does not look useful to overall QEMU I will fold it int= o my >>> other out-of-tree patches. >>=20 >> I think the per-vcpu tracing feature is reasonable for qemu.git as long >> as it does not introduce performance regressions for existing users. > I'm okay with it if the dstate array is changed to uint16_t. That should be fine. I don't think QEMU is gonna run more than 2**16 vCPUs anytime soon :) Cheers, Lluis