[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] Update on TCG Multithreading
From: |
Lluís Vilanova |
Subject: |
Re: [Qemu-devel] Update on TCG Multithreading |
Date: |
Mon, 01 Dec 2014 19:41:02 -0600 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.4 (gnu/linux) |
Alexander Graf writes:
> 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 ;).
Ooops, true; at least probably, since you're never sure how much the HW
prefetcher is going to outsmart you :)
Well, I guess that a define will have to do then. But I think it still makes
sense to refactor tb_* functions and such to have a TCGCache as first argument.
Best,
Lluis
--
"And it's much the same thing with knowledge, for whenever you learn
something new, the whole world becomes that much richer."
-- The Princess of Pure Reason, as told by Norton Juster in The Phantom
Tollbooth