Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 26 Oct 1999 02:26:34 +0000 (GMT)
From:      Terry Lambert <tlambert@primenet.com>
To:        freebsd@gndrsh.dnsmgr.net (Rodney W. Grimes)
Cc:        tlambert@primenet.com, twinkle.star@263.net, freebsd-smp@FreeBSD.ORG
Subject:   Re: inquire(second time)
Message-ID:  <199910260226.TAA26348@usr06.primenet.com>
In-Reply-To: <199910260214.TAA19260@gndrsh.dnsmgr.net> from "Rodney W. Grimes" at Oct 25, 99 07:14:44 pm

next in thread | previous in thread | raw e-mail | index | archive | help
> > The need to exclusively access the I/O bus is one of the main
> > factors sited for the developing RAMBus technology coming from
> > major vendors.
> 
> 
> You had better go sit in the corner and think about that real
> real real hard.  RAMBus technology in no way effects exclusive
> access to the I/O bus.  That is purely in the domain of the
> CPU / IO bridge chip, and no place near the CPU / Memory controller
> bridge chip.
> 
> The main factor driving RAMBus and other fast memory technologies
> is the fact that our CPU cores are now running in production at 2
> to 4 times the data rate of the fastest memory system designs in
> production.  And thats for a single CPU design.  The problem of
> CPU demand vs memory bandwidth is only aggrevated, and thusly
> requireing a faster memory subsystem, by SMP.

It was my understanding that this would apply to memory mapped I/O,
as well, but of course I haven't investigated RAMBus closely enough
(obviously) to be able to say for sure.

The idea I was trying to communicate is that memory mapped I/O is
a hell of a lot more friendly to SMP than inb/outb based device
communication (c.v. my keyboard LED example later in the posting).

Anyway, if the RAMBus stuff is useless for direct memory mapped
regions on devices (e.g. they can't come in except via slower
memory elsewhere), then consider me thwacked.  8-).


					Terry Lambert
					terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-smp" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199910260226.TAA26348>