Originally posted by: dmens
Originally posted by: designit
When you share, you also fight, just like two kids sharing a single toy will fight for it. Thrashing is well known problem in paged memory multi-tasking systems, when it happens, too many tasks compets for memory and the system spends most of its time in paging activity between the memory and the disk. From a user's view, the system basically comes to a halt. With shared cache multi-core designs like INTEL Yonah, multiple cores fight for cache. Cache thrashing will become a common phenomenon inside the INTEL CPUs.
help me.......master..... I am freez.......ing...burrrrrr. system halt... system halt....syssssssssssssssssssssssssss....... a moment of silence please.
LOL, that sharikou (PhD!!!) guy is totally clueless. He claims merom/yonah will suffer from L2 cache thrashing simply because the L2 cache is shared and accessible by either core. But since the L2 is physically tagged... so much for that!
He uses a hyperthreading example to justify his claim even though neither yonah nor merom has SMT, and I doubt he has any clue how exactly HT is negatively impacted by the particular example given in the MSDN blog post. With two processes on one core and the helper thread taking control of large chunks of the caches, the worker thread is forced to refetch continuously. But with just a shared L2 and no SMT, it is *no dfferent* than a physically partitioned L2.
Even his analysis of thrashing is wrong, he makes it sound like the CPU livelocks, even though with the given worker/helper scenario, it is not possible.
Not so. SMT and worker/helper are only effective when one application uses lesser block of memory than the other. When each application needs to process large memory blocks at a time(more than the shared cache can afford), you end up having rapid alternating effect between the 2, a "ping pong" scenario as Shariko explained.