qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Our use of #include is undisciplined, and what to do ab


From: Dr. David Alan Gilbert
Subject: Re: [Qemu-devel] Our use of #include is undisciplined, and what to do about it
Date: Thu, 17 Mar 2016 19:43:03 +0000
User-agent: Mutt/1.5.24 (2015-08-30)

* Paolo Bonzini (address@hidden) 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 / address@hidden / Manchester, UK



reply via email to

[Prev in Thread] Current Thread [Next in Thread]