|
From: Julian S. <js...@ac...> - 2005-06-22 13:22:58
|
Thanks for the info. > The easiest and best way on ppc32 to know the cache line size and > whether we have altivec is to look in the aux vector. Fine, ok. That does mean reading the aux vector before initialising Vex, but that's OK. > The cache line size is also needed for implementing icbi, which ends > up invalidating cached block translations. Yeh ... we stared at that one for a while. It seems that icbi can be safely implemented assuming any cache line size which is a power of 2 and >= the real cache line size, so we initially used 256. It just means more translations than necessary get thrown away, which affects performance but not correctness. Unfortunately such an approximation obviously doesn't work with dcbz. --- Re invalidations, I was going to ask: throwing stuff out of the (V's) translation cache is tremendously expensive as it involves a linear search of all translations. That means performance will suffer badly if the client does a lot of icbis. Is that something you noticed to be a problem with 2.4.0-ppc ? The translation cache stuff could be redesigned (I suppose) to convert invalidation cost from O(N) to O(log N) or O(handwaving-hashtable-cost N) kinda thing, but that's significant hassle that I'd rather avoid if not necessary. J |