From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:54586)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <paolo.bonzini@gmail.com>) id 1agdUg-0000Mh-Oh
	for qemu-devel@nongnu.org; Thu, 17 Mar 2016 15:22:03 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <paolo.bonzini@gmail.com>) id 1agdUd-00085l-Jr
	for qemu-devel@nongnu.org; Thu, 17 Mar 2016 15:22:02 -0400
Received: from mail-wm0-x236.google.com ([2a00:1450:400c:c09::236]:34392)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <paolo.bonzini@gmail.com>) id 1agdUd-00085b-9Z
	for qemu-devel@nongnu.org; Thu, 17 Mar 2016 15:21:59 -0400
Received: by mail-wm0-x236.google.com with SMTP id p65so40248021wmp.1
	for <qemu-devel@nongnu.org>; Thu, 17 Mar 2016 12:21:58 -0700 (PDT)
Sender: Paolo Bonzini <paolo.bonzini@gmail.com>
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>
From: Paolo Bonzini <pbonzini@redhat.com>
Message-ID: <56EB03D0.6010209@redhat.com>
Date: Thu, 17 Mar 2016 20:21:52 +0100
MIME-Version: 1.0
In-Reply-To: <20160317162900.GK5966@work-vm>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
Subject: Re: [Qemu-devel] Our use of #include is undisciplined,
	and what to do about it
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: "Dr. David Alan Gilbert" <dgilbert@redhat.com>, Stefan Hajnoczi <stefanha@redhat.com>
Cc: qemu-devel@nongnu.org, Peter Maydell <peter.maydell@linaro.org>, Richard Henderson <rth@twiddle.net>, =?UTF-8?Q?Llu=c3=ads_Vilanova?= <vilanova@ac.upc.edu>, Markus Armbruster <armbru@redhat.com>

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?

> 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.

Paolo