From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59633) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1agdpC-0002xm-89 for qemu-devel@nongnu.org; Thu, 17 Mar 2016 15:43:15 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1agdp6-0005sl-AH for qemu-devel@nongnu.org; Thu, 17 Mar 2016 15:43:14 -0400 Received: from mx1.redhat.com ([209.132.183.28]:51296) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1agdp6-0005sh-59 for qemu-devel@nongnu.org; Thu, 17 Mar 2016 15:43:08 -0400 Date: Thu, 17 Mar 2016 19:43:03 +0000 From: "Dr. David Alan Gilbert" Message-ID: <20160317194303.GP5966@work-vm> References: <87wpp4m6n1.fsf@blackfin.pond.sub.org> <20160315133916.GM27203@stefanha-x1.localdomain> <20160315135647.GB11728@work-vm> <20160316182343.GE2012@stefanha-x1.localdomain> <20160316182748.GG2246@work-vm> <20160317112508.GG14062@stefanha-x1.localdomain> <20160317162900.GK5966@work-vm> <56EB03D0.6010209@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56EB03D0.6010209@redhat.com> Subject: Re: [Qemu-devel] Our use of #include is undisciplined, and what to do about it List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: Peter Maydell , qemu-devel@nongnu.org, Markus Armbruster , Stefan Hajnoczi , =?iso-8859-1?Q?Llu=EDs?= Vilanova , Richard Henderson * Paolo Bonzini (pbonzini@redhat.com) wrote: > On 17/03/2016 17:29, Dr. David Alan Gilbert wrote: > > OK, so I see TraceEvent has a TraceEventID field; so yes that works easily; > > it turns out to be a little more expensive though since what was a: > > > > trace_events_dstate[id] > > > > is now > > trace_events_dstate[te->id] > > That however makes you waste a lot of cache on trace_events_dstate > (commit 585ec72, "trace: track enabled events in a separate array", > 2016-02-03). > > Perhaps we get the linker to do compute the id, for example by using a > separate data section and then use te-&te_first to compute the id... > Richard, do you have ideas on how to do this in a reasonably portable > manner? It's possible we don't need the unique-id on the fast-path; for example if we had an id that was only unique within each trace-events file, and it's own trace_events_dstate[] that used that ID, then that would still be a nice statically known id. You'd still need to be able to get the global ID for the simple-event and anything else that needed it. > > But hang on, what's the 'sstate' in TraceEvent; do we actually need two > > state fields if we're passing a TraceEvent pointer around? > > sstate means the event is unavailable, it's basically just a way to > provide better error messages. Dave > > Paolo -- Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK