[Top][All Lists]

[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 21:59:15 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0

On 17/03/2016 21:14, Richard Henderson wrote:
> On 03/17/2016 12:21 PM, Paolo Bonzini wrote:
>> 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).
> I must say I'm not really convinced by that patch, since I don't see that
> there's much locality between the ID's that would be polled.

There are usually just three-four files in hot paths; they could be
kvm-all.c, memory.c, hw/virtio/virtio.c and hw/block/virtio-blk.c for a
disk benchmark for example.  All tracepoints for a file are adjacent,
hence the trace_events_dstate portion that represents one file (assuming
that file has <=64 events) costs 1-2 cache lines.  Without the patch the
footprint of trace_events is 1 cache line for every 2-3 events since
sizeof(TraceEvent) == 24.

It's true that the patch before 585ec72 also helps removing overhead in
the case where all events are disabled (and that's the really common
case).  That obviously avoids consuming _any_ amount of cache on
disabled trace events.  However I believe that separate dstate arrays
are anyway helpful for David's plan to split the generated tracing
headers and avoid world rebuilds.  That's because the headers only need
the dstate arrays and not the big global arrays.


reply via email to

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