From: Alexander Graf <agraf@suse.de>
To: "Mark Burton" <mark.burton@greensocs.com>,
qemu-devel <qemu-devel@nongnu.org>,
"Bastian Koppelmann" <kbastian@mail.uni-paderborn.de>,
"pavel Dovgaluk" <Pavel.Dovgaluk@ispras.ru>,
"KONRAD Frédéric" <fred.konrad@greensocs.com>,
"Peter Maydell" <peter.maydell@linaro.org>,
"Dr. David Alan Gilbert" <dgilbert@redhat.com>,
"Alex Bennée" <alex.bennee@linaro.org>,
"Paolo Bonzini" <pbonzini@redhat.com>
Subject: Re: [Qemu-devel] Update on TCG Multithreading
Date: Tue, 02 Dec 2014 00:45:02 +0100 [thread overview]
Message-ID: <547CFD7E.1080409@suse.de> (raw)
In-Reply-To: <87tx1faxvk.fsf@fimbulvetr.bsc.es>
On 01.12.14 22:00, Lluís Vilanova wrote:
> Mark Burton writes:
>
>> All - first a huge thanks for those who have contributed, and those who have
>> expressed an interest in helping out.
>
>> One issue I’d like to see more opinions on is the question of a cache per core,
>> or a shared cache.
>> I have heard anecdotal evidence that a shared cache gives a major performance
>> benefit….
>> Does anybody have anything more concrete?
>> (of course we will get numbers in the end if we implement the hybrid scheme as
>> suggested in the wiki - but I’d still appreciate any feedback).
>
> I think it makes sense to have a per-core pointer to a qom TCGCacheClass. That
> can then have its own methods for working with updates, making it much simpler
> to work with different implementations, like completely avoiding locks (per-cpu
> cache) or a hybrid approach like the one described in the wiki.
I don't think you want to have indirect function calls in the fast path ;).
Alex
next prev parent reply other threads:[~2014-12-01 23:45 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-01 19:33 [Qemu-devel] Update on TCG Multithreading Mark Burton
2014-12-01 21:00 ` Lluís Vilanova
2014-12-01 23:45 ` Alexander Graf [this message]
2014-12-02 1:41 ` Lluís Vilanova
2014-12-02 10:14 ` Dr. David Alan Gilbert
2014-12-02 15:14 ` Kirill Batuzov
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=547CFD7E.1080409@suse.de \
--to=agraf@suse.de \
--cc=Pavel.Dovgaluk@ispras.ru \
--cc=alex.bennee@linaro.org \
--cc=dgilbert@redhat.com \
--cc=fred.konrad@greensocs.com \
--cc=kbastian@mail.uni-paderborn.de \
--cc=mark.burton@greensocs.com \
--cc=pbonzini@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
/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.