Kai Harrekilde-Petersen
Guest
|
 Posted:
Fri Nov 11, 2005 1:15 am Post subject:
Re: Memory controller state of the art? |
|
|
Andy Glew <andy.glew@intel.com> writes:
| Quote: | From my point of view, you'd need either a mechanism to accept that
some of your speculative accesses simply got "killed" (ie no
response/data is returned), or that you return a "failed" response
(could be either a status flag or deliberately bogus data. I'd go for
the first option).
If you were to implement throttling of speculative accesses, how would
you do it?
I'd go for the second option, a failed response - speculative NACK,
retry when nonspeculative.
|
I agree - when I reread that paragraph above, I realized the "first"
pointed back to "no response" rather than "return NACK". My bad.
But how would to determine to when to throttle? - Again, as I see it,
you could keep a counter of max speculative requests accepted at a
router/memory controller, or only actively NACK'ing speculative
requests when they were stealing bandwidth from "real" requests, or
power throttling told the memory controller to back off.
I guess you could implement all three independently, but I assume that
the latter two would be the best ideas.
Kai
--
Kai Harrekilde-Petersen <khp(at)harrekilde(dot)dk> |
|
Peter \"Firefly\" Lund
Guest
|
| Posted:
Fri Nov 11, 2005 4:11 pm Post subject:
Re: Memory controller state of the art? |
|
|
On Thu, 10 Nov 2005, Andy Glew wrote:
| Quote: | request tagged speculative, indicating that it was memory mappped I/O
and should be retried when the request was no longer speculative.
|
Cute.
| Quote: | To prevent excessive traffic, I wanted to cache the tupe of memory
returned from the chipset in the TLBs, so that successive requests to
the same pagedid not go through the speculative-NACK-nonspeculative
cycle.
|
I guess the interactions with the different page sizes got interesting...
| Quote: | However, we could have taken the same approach, of having the chipset
tell us about the memory typeof a region, and then cache it in the TLV
so that subsequent accesses could have been write combined.
|
Yep.
| Quote: | Still, I think that we might still have used the MTRRs. But, they
would not have had to cover all of memory, which demands a large
number of MTRRs. Instead, they would have only had to cover the USWC
regions.
Or, we could have depended on the page tables. Although the page
tables came later - Lance hacking did not invent the PAT until after
P6 was over.
|
The PAT is nicer for the OS.
| Quote: | i486 and Pentium (P5) chipsets had to respond with the cacheability to
the processor on every requeest. Real fast. Always a timing path.
|
Ouch, I didn't know that. Nasty.
| Quote: | At one time the P6 MTRRs were supposed to have several bits that would
go out onto the bus - the idea being that the MTRRs would be
programmed with the routing. Thus removing the chipset tables (except
|
Nice :)
-Peter |
|
FAQ
Memberlist
Register
Profile
Log in to check your private messages
Log in