CASTalk.com

Guest

How sophisticated are current and near future memory controllers?
ISTR reading that the Alpha 21364 (EV7) memory controllers have a
somewhat simple albeit intelligent page-open policy, but I do not
recall reading anything about more sophisticated features like
prioritizing accesses according to urgency (e.g., demand reads
having priority over bufferable writes and prefetches) or to
maximize throughput (e.g., reordering accesses to minimize the
number of page closings and openings).

An integrated memory controller could also enqueue accesses that
have not yet been confirmed as L2/L3 cache misses, checking
whether the DRAM page is open and performing some prioritization
work while waiting for the access to be canceled or confirmed.
Integration also makes more aggressive prefetching and more
intelligent and aggressive eager writeback feasible because
likely to be dropped prefetch requests can be sent (only wasting
less expensive on-chip bandwidth) and eager writeback can
interact with the knowledge of which DRAM pages are open and
busy. (Obviously memory attached to a remote controller would
have to be handled more conservatively, though the connection to
an adjacent memory controller might have enough surplus bandwidth
to allow the open DRAM page tags to be mirrored allowing
potential prefetches [or eager writebacks] to adjacent memories
to be prioritized and possibly delayed.)

Providing a specialized zeroed-page cache at the memory
controller might be worthwhile (though one might also want to
flag zero-page TLB entries as well to reduce latency of cache
block zeroing on a read or a page zeroing on a write).

An FB-DIMM-like architecture could allow for further complexity
in memory access scheduling by allowing write buffers and
prefetch caches to be located and partially managed at the memory
module (managing memory controller to buffer chip and buffer chip
to DRAM [and ideally on-DRAM SRAM buffer/cache to DRAM array]
bandwidth). Placing a cache on the first and/or second FB-DIMM
could allow more aggressive partial (e.g., distant FB-DIMM to
near FB-DIMM cache) prefetching since distant FB-DIMM to near
FB-DIMM bandwidth is cheaper than first FB-DIMM to memory
controller bandwidth. (ISTR reading that initial FB-DIMM memory
sytems will not take advantage of the potential NUMA character of
the architecture, which is a bit disappointing. BTW, would it be
reasonable to integrate the first buffer chips very near the
processor/memory controller [possibly the same package?] and have
the first modules share the processor board to provide higher
bandwidth from the first buffer chips and lower latency to the
first few GiB of memory?)

Paul A. Clayton
a babbling not-quite-idiot :-\

Iain McClatchie · Guest

I note that if the cache line is 64B and the DDR memory channel
is 64 or 72b, then you have 8 bits on the data pins per transaction,
and 4 bits on the address pins per transaction. A
read keeps the bank busy for many cycles, maybe 8-10.

RAS and CAS only take 2, so you can issue 2 more. If a read keeps
a bank busy for many cycles, say 10, and there are 4 banks then if
the data bus is saturated the banks are only a little more than
half busy on average. So we have the opportunity and motive to
kick off some speculative RAS operations. Speculative CAS is
different since they chew up the data bus, which has nominally
higher utilization.

Some things are pretty clear:

* If you have a load miss, you'll want to get that RAS and CAS out
ahead of any writes to the same bank, unless the write buffer is
full.

Some things are not:

* When you have a free address bus slot coming up, if you fire a
speculative RAS, the benefit of lower latency if you are right
(and a load miss does need the data, maybe 3 address cycles
won) has to outweigh the loss if you are wrong (some other load
miss to that bank needs data, maybe 6-10 address cycles lost
because the bank has to be precharged).
* Speculating that the last RAS to a bank will also cover the next
access has to be given extra weight, since firing a different
RAS costs power.

Here's my final twist: My guess is that lots of business laptops
do not need 3D graphics, and would benefit more from the power
and cost savings of having graphics and CPU on the same die,
using the same DRAM. So with both devices hitting the same DRAMs,
and advance/speculative information about CPU accesses, are there
interesting strategies to get bandwidth to the GPU and low latency
to the CPU?

Intel, ATI, and Nvidia have of course seen this issue in their
integrated northbridge/graphics products, but they have not dealt
with it in the presence of speculative information from the CPU.

Ken Hagan · Guest

Iain McClatchie wrote:

Iain McClatchie · Guest

Ken> I'd have thought a GPU was almost entirely redundant for such
laptops,
Ken> so we could just do all the display stuff in software, like we did
15
Ken> or 20 years ago.

Well:
- 2D compositing hardware, for things like antialiased text and
presentation
graphics, is very, very small.
- Doing stuff in hardware takes a lot less power than doing it in
software.
So if you can afford the hardware (it's small enough to integrate,
and you
will be using it often enough), throw it in.

Frankly, I thought the PA-semi presentation looked like the future.
Not exactly
a laptop chip (CPU core too slow, no graphics, no RAMDAC), but close.

Didn't AMD have a Geode thing that was basically what I'm talking
about,
only not fast enough to be satisfying under MS Windows?

Niels Jørgen Kruse · Guest

Iain McClatchie <iain-3@truecircuits.com> wrote:

David Wang · Guest

MitchAlsup@aol.com wrote:

Guest

MitchAlsup@aol.com wrote:

Guest

All opf your musings in the first two paragraphs are implemented in the
Opteron On-die memory controllers.

But I think you are way overestimating the utility of FB-DIMM
technology. I see FB-DIMMs are a size play (4X) at the cost of latency
(+20%). Therefore those applications (like data bases) that respond
well to size increases at the cost of added latency will enjoy the
benefits of FB-DIMM. I am sure that business/productivity applications
will loose performance on FB-DIMM systems, and I believe that 3X as
many FP applications will loose performance as will gain performance
with FB-DIMM. And this comes from the viewpoint of having run these
applications on a very agressive "memory and DRAM controller"
simulators.

Del Cecchi · Guest

<Dysthymicdolt@aol.com> wrote in message
news:1131145922.492341.306900@z14g2000cwz.googlegroups.com...

Guest

David Wang wrote:
[snip]

David Kanter · Guest

Iain McClatchie · Guest

Mitch> All opf your musings in the first two paragraphs are implemented
Mitch> in the Opteron On-die memory controllers.

Each Opteron chip knows the page open status of the remote Opterons?
:)

I presume that accesses to remote memories are not started
speculatively. If that's true, does it mean we can measure the gain
from the speculative local memory operations by comparing runtimes
on local memory versus runtimes on remote memory, and
subtracting the additional remote latency * cache misses?

Guest

David Kanter wrote
[snip]:

David Wang · Guest

Dysthymicdolt@aol.com wrote:

David Kanter · Guest

Memory controller state of the art? Goto page 1, 2, 3 Next

	CASTalk.com Forum Index -> Computer Architecture	All times are GMT Goto page 1, 2, 3 Next
Page 1 of 3