[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: |
Paolo Bonzini |
Subject: |
Re: [Qemu-devel] Our use of #include is undisciplined, and what to do about it |
Date: |
Thu, 17 Mar 2016 20:58:43 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 |
On 17/03/2016 20:21, Paolo Bonzini 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?
Dave and I actually got to a much better design on IRC.
1) since the .h files will be per-directory, make the dstate array per
directory (e.g. trace_events_dstate_migration[])
2) changes must have no effect on unrelated .h files, but we can keep a
global .c file. Instead of using trace_events_dstate[te->id], we can
store a pointer directly in te, e.g. ".p_dstate =
&trace_events_dstate_migration[23]" and then *(te->p_dstate). The
global .c file can also store mappings from local id to global id, so
that the global id can be retrieved with "trace_events_ids_migration[23]".
Processing trace-events would remain a global process, but unchanged .h
files would not be changed on disk and would not trigger the world.
Splitting the input to tracetool becomes a separate task from splitting
its output, and could be achieved simply by introducing include directives.
Paolo
- Re: [Qemu-devel] Our use of #include is undisciplined, and what to do about it, (continued)
- Re: [Qemu-devel] Our use of #include is undisciplined, and what to do about it, Stefan Hajnoczi, 2016/03/15
- Re: [Qemu-devel] Our use of #include is undisciplined, and what to do about it, Daniel P. Berrange, 2016/03/15
- Re: [Qemu-devel] Our use of #include is undisciplined, and what to do about it, Dr. David Alan Gilbert, 2016/03/15
- Re: [Qemu-devel] Our use of #include is undisciplined, and what to do about it, Stefan Hajnoczi, 2016/03/16
- Re: [Qemu-devel] Our use of #include is undisciplined, and what to do about it, Dr. David Alan Gilbert, 2016/03/16
- Re: [Qemu-devel] Our use of #include is undisciplined, and what to do about it, Stefan Hajnoczi, 2016/03/17
- Re: [Qemu-devel] Our use of #include is undisciplined, and what to do about it, Dr. David Alan Gilbert, 2016/03/17
- Re: [Qemu-devel] Our use of #include is undisciplined, and what to do about it, Paolo Bonzini, 2016/03/17
- Re: [Qemu-devel] Our use of #include is undisciplined, and what to do about it, Dr. David Alan Gilbert, 2016/03/17
- Re: [Qemu-devel] Our use of #include is undisciplined, and what to do about it,
Paolo Bonzini <=
- Re: [Qemu-devel] Our use of #include is undisciplined, and what to do about it, Richard Henderson, 2016/03/17
- Re: [Qemu-devel] Our use of #include is undisciplined, and what to do about it, Peter Maydell, 2016/03/17
- Re: [Qemu-devel] Our use of #include is undisciplined, and what to do about it, Richard Henderson, 2016/03/17
- Re: [Qemu-devel] Our use of #include is undisciplined, and what to do about it, Paolo Bonzini, 2016/03/17
- Re: [Qemu-devel] Our use of #include is undisciplined, and what to do about it, Paolo Bonzini, 2016/03/17
Re: [Qemu-devel] Our use of #include is undisciplined, and what to do about it, Richard Henderson, 2016/03/17