Silicon Investor (SI) -- The First Internet Community

STOCKTALK

We've detected that you're using an ad content blocking browser plug-in or feature. Ads provide a critical source of revenue to the continued operation of Silicon Investor. We ask that you disable ad blocking while on Silicon Investor in the best interests of our community. If you are not using an ad blocker but are still receiving this message, make sure your browser's tracking protection is set to the 'standard' level.

Technology Stocks : Advanced Micro Devices - Moderated (AMD) -- Ignore unavailable to you. Want to Upgrade?

To: Petz who wrote (80863)	5/28/2002 8:08:48 PM
From: wanna_bmw	Read Replies (3) \| Respond to of 275872

John Petzinger, Re: "Please admit that you were simply WRONG when you implied that a cache-line "invalidation" ALWAYS results in that cacheline being FLUSHED and WRITTEN INTO MEMORY. It just AIN'T SO." Forget to turn the CAPS LOCK off? If you claim to know what I implied, then you are making dense ASSumptions, just like your friend Ali. Get it right. You quoted me right below, so why do you lie like you do above? "Flushing" and "invalidating" are the same thing, as long as a line is owned by a caching device (processor or I/O hub), but is not in modified state. If the line has been modified, it will get written back to main memory. Don't mince the words. Flushing has been defined in the dictionary as forcing temporarily buffered data to be written to more permanent memory, and if data is getting written back because it has been modified, then the state of the cache line still gets marked invalidated. Therefore, I don't see a huge difference if the data has not been modified, and does not get written back, because as you so obtusely point out, it doesn't need to if the data hasn't been changed. Has the snooping process changed at all? Does the cache line no longer need to be forced invalid? No, and no. As I see it, the line has been flushed from cache, since there is no longer a reference to it. I argue with Ali because he nit-picks people's wording, and makes a big deal about it, and all the while, he misses the real point of the argument. You look like you're doing the same thing with the way I justify Ace's use of the word "flush". If all you or Ali wanted to say was that Ace's misused the word from the generally accepted definition, then that's all you had to say. Instead, Ali goes on a long diatribe about unprofessional journalism, and challenges my career experience when I attempt to defend it. I've already said that Ace's misses a few key points, but I don't believe it makes a difference to their target audience. That's my contribution, and if you don't agree, then fine - take it or leave it, as anyone is welcome to do on this forum. But if you want to change the argument into the proper definition of the word "flush", and insult me in the process, then I don't care to continue. As I suggested to your bud, consider taking an anger management class, and learn some manners besides. I don't deserve to have my comments attacked the way you have done. wbmw

To: Petz who wrote (80863)	5/28/2002 11:52:47 PM
From: Ali Chen	Respond to of 275872

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