From: Paolo Bonzini <pbonzini@redhat.com>
To: Richard Henderson <rth@twiddle.net>,
"Dr. David Alan Gilbert" <dgilbert@redhat.com>,
Stefan Hajnoczi <stefanha@redhat.com>
Cc: "Lluís Vilanova" <vilanova@ac.upc.edu>,
"Peter Maydell" <peter.maydell@linaro.org>,
qemu-devel@nongnu.org, "Markus Armbruster" <armbru@redhat.com>
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 [thread overview]
Message-ID: <56EB1AA3.5040305@redhat.com> (raw)
In-Reply-To: <56EB1021.5040100@twiddle.net>
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.
Paolo
next prev parent reply other threads:[~2016-03-17 20:59 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-15 9:29 [Qemu-devel] Our use of #include is undisciplined, and what to do about it Markus Armbruster
2016-03-15 9:40 ` Paolo Bonzini
2016-03-15 12:19 ` Markus Armbruster
2016-03-15 14:51 ` Paolo Bonzini
2016-03-15 10:03 ` Peter Maydell
2016-03-15 12:28 ` Markus Armbruster
2016-03-15 12:56 ` Peter Maydell
2016-03-15 13:39 ` Stefan Hajnoczi
2016-03-15 13:51 ` Daniel P. Berrange
2016-03-15 13:56 ` Dr. David Alan Gilbert
2016-03-16 18:23 ` Stefan Hajnoczi
2016-03-16 18:27 ` Dr. David Alan Gilbert
2016-03-17 11:25 ` Stefan Hajnoczi
2016-03-17 16:29 ` Dr. David Alan Gilbert
2016-03-17 19:21 ` Paolo Bonzini
2016-03-17 19:43 ` Dr. David Alan Gilbert
2016-03-17 19:58 ` Paolo Bonzini
2016-03-17 20:14 ` Richard Henderson
2016-03-17 20:27 ` Peter Maydell
2016-03-17 20:29 ` Richard Henderson
2016-03-17 21:02 ` Paolo Bonzini
2016-03-17 20:59 ` Paolo Bonzini [this message]
2016-03-17 19:40 ` Richard Henderson
2019-05-27 13:12 ` Markus Armbruster
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=56EB1AA3.5040305@redhat.com \
--to=pbonzini@redhat.com \
--cc=armbru@redhat.com \
--cc=dgilbert@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=rth@twiddle.net \
--cc=stefanha@redhat.com \
--cc=vilanova@ac.upc.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.