On 10.05.2011 13:26, Kristoffer Glembo wrote:
The cache can generate a hit after a context switch if there exists cache lines
belonging to the newly switched in process.
Is this really possible? You mean that the cache line has "survived"
during the execution of the last timeslice of another (i.e. different)
task AND that the last and the new task have shared a memory region AND
this shared memory region is susceptible to virtual aliasing in the data
cache AND the last task has actually written to one of these virtual
addresses AND the new task actually reads from exactly this virtual
alias address that the last task wrote to?
This seems very unlikely to me but I must admit that you have a point
here. It is possible in theory, though very unlikely.
But then what is the context number stored for every cache line for?
Only for the case when you have a tiny cache with the lowest possible
associativity that you can save a few cycle on a context switch? People
want _big_ caches with _high_ associativity in order to improve the hit
rate. Having a bigger cache even if you have to flush it on a context
switch is much better for performance than having a tiny one without a
flush. Why do you waste so much hardware on a feature that has so little
benefit?
You could avoid this if you always make shared memory regions non-cacheable. I don't know
enough to say whether this is currently possible.
I don't think this is a good idea. It is propably better to still use
caches and flush the caches on a context switch than making these
regions uncacheable at all. This will propably slow down access to these
regions too much.
I think Daniel meant a solution to the cache coherency problem. It is possible to
fully avoid aliases in hardware.
Ah yes, of course.
What terminology do you have a problem with in the Linux kernel? That it is written
"set size" instead of "way size" in some comments? I don't think "set size" is an uncommon
alias for "way size" ...
But I do. A cache set consists of all cache lines in a cache that can
store data belonging to addresses that have the same index (i.e. the
"middle" part of the cache address is the same for all cache lines in a
cache set). The way size is the sum of all cache lines that belong to a
certain way, i.e. the n-th possiblity within a cache set to store and
retrieve a cache line. Way zero is the first possibility in each set;
Way one is the second and so on...
Cache lines belonging to the same way don't necessarily have any address
bits in common. Whereas the cache lines belonging to a cache set do...
By the way: If it is correct what you say then why was this changed for
the Leon4 manual? Leon2 and 3 manuals use the wrong terminology while
the Leon4 manual uses the correct one. Obviously, there must be at least
one person at Gaisler who believes that the previous terminology was not
correct. Leon2 and 3 manual mention "multi-set caches" while
Leon4-manual mentions "multi-way caches". Look at the GRLIB ipcore
user's manual.
One thing in addition: Please don't get me wrong. I don't want to blame
anybody too much. I just would like to see consistent terminology in the
code so it is easier for everybody to understand. That's all I am aiming
for.
Thanks,
Matthias
--
To unsubscribe from this list: send the line "unsubscribe sparclinux" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
