Petz, "invalidation" and "flushing"
Actually, I was not entirely accurate in my statements
either, about complete independence of these two things.
There are eccentric cases when two processors
may want to update two different words in the same
cacheline, so every write hits a modified cachline,
and the line has to be flushed on every writes. However, the
talk was about peripheral I/O doing bus mastering, which
usually happens for big blocks of data, when cachelines
get completely re-written.
Even with worst-case USB programming
(very low granularity of descriptors), when a USB device
updates its status, it usually writes to a cacheline
that was previously read from, so it already was coherent
with any of processor caches.
I guess wanna wanted to bring this example in, but
apparently could not spell it out coherently,
due to numerous confusions
(cache flush vs. cacheline flush, all versus write-backs,
s/he forgot to specify which cache replacement policy she
has in mind, write-back or write-through). S/he does not
understahd who snoops the bus and when, apparently confuses
snooping with snarfing, verification with validation,
belives that chipset does all the work (unless s/he is
working on Athlon/Hammer chipsets ;-), etc.etc. S/he
behaves as s/he wrote the Ace's article.
BTW, my excerpt from the Ace's article was not the most
characteristic one. I still maintain that the level
of Ace's "analysis" is brutally inadequate to the
challenge of explaining difficulties in MP scalability,
since the scalability critically depends on all those
tricks with write-back or not, write-combine or not,
write allocate or not, weak write ordering or strong,
etc. etc.
And thanks for your support. You see how furious s/he
become after you made few remarks. It is worth to study
what kind of tactics s/he pulled on me, just to pick up
a fight about nothing, about some poor journalism. Funny.
- Ali |
