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
