| Author |
Message |
Keith Williams
Guest
|
 Posted:
Wed Dec 07, 2005 5:15 pm Post subject:
Re: pci and caching |
|
|
In article <43965eb9$0$22304$5a62ac22@per-qv1-newsreader-
01.iinet.net.au>, markm@vl.com.au says...
| Quote: | Keith Williams wrote:
prefetching <> cacheing
OK, but I believe it is right to say that *only* prefetchable memory can
(also) be cacheable?
|
Ok, I can't think of a case where one would want data to be cached
but not prefetchable. I suppose I could come up with some weird
case where data is changed on read but it's needed several times.
Of course one would simply copy the data into memory (or register).
I suppose: cacheable => prefetchable,
but prefetchable /=> cacheable
^
+- does not
| Quote: | But it *is* part of the (pre 2.2) spec. The bus must guarantee
coherency in this case. The way it does it is with back-offs and
retries. Now think about this with multiple bridges and initiators.
It gets to be a mess.
Which is exactly why I was surprised that they (PCISIG) would even
attempt to handle it! :O Thinking about it, I suppose if the bus doesn't
specify it, then what other scope to do so is there?
It's there in the older versions of the spec. As I've mentioned,
it's been deprecated in later versions.
OK, I stand corrected. Although I have worked on pre 2.2 designs, this
was never an issue so it was duly forgotten.
|
I've never seen it used either. The SBO# and SDONE signals are
tied off in the designs I've seen/done (but there). I only
remembered it from a MindShare PCI class I took moons ago. The
instructor didn't much like it either. ;-)
| Quote: | I've learnt something new today. Can I go home now? ;)
|
Got coffee in hand. It's just time to get started! ;-)
--
Keith |
|
| Back to top |
|
 |
TC
Guest
|
| Posted:
Thu Dec 08, 2005 9:15 am Post subject:
Re: pci and caching |
|
|
"Mark McDougall" <markm@vl.com.au> wrote in message
news:4393bb75$0$23327$5a62ac22@per-qv1-newsreader-01.iinet.net.au...
| Quote: | Keith wrote:
That doesn't change the cacheability. Caches are a processor thing
and *NOT* under control of any PCI device.
Which begs the question, why would the PCI spec refer to something that
has nothing to do with PCI?
If a PCI memory space is marked as 'pre-fetchable' then it guarantees,
among other things, that the act of pre-fetching memory has no
side-effects. This means nothing more than the fact that it may be a
suitable candidate for caching, if the platform supports it. In this case,
a master may issue MRL (& MRM) commands.
OTOH, cache-coherency (which I assume you're hinting at) is a different
problem altogether - especially if you've got multiple bus masters
accessing PCI memory space with their own caches. However, this is a
*system* problem and (IMHO) not really any concern of the PCI bus spec
group to mandate that PCI memory is not 'cacheable' - whatever that means
in each context!
In fact, there's little discussion what-so-ever in the spec (that I can
see) about 'caches' - which is just what I would expect.
BTW I'm quite happy to be shown the error in my reasoning!
Regards,
Mark
|
PCI devices (peripherals) identify via Base Address Registers (BARs) the
size and type(s) of address space (IO, memory or prefecthable memory) that
they need the BIOS and/or operating system (plug and play code) to be mapped
as physical addresses on the bus. These addresses are typically accesed by
device drivers (but might also be accessed by other devices). The statement
that...
"If a PCI memory space is marked as 'pre-fetchable' then it guarantees,
among other things, that the act of pre-fetching memory has no
side-effects."
.... is the best summary statement of the signifigance of 'pre-fetchable'
memory on PCI. It is used purely as a performance optimization that allows
for use of burst read transactions (specifically MRL and MRM) when accessing
that address region.
This has nothing to do with cacheing. While the original PCI specification
envisioned the ability to have cacheable memory accessed via the PCI bus
(and includes SBO# and SDONE to implement a cache coherency protocol for
PCI) I am unaware of any system or design that ever implemented this. In
subsequent specifications (i.e. PCI 2.2) it was made clear that this
functionality was being demoted and marked for removal in future
specification revisions.
Hope this helps.
TC |
|
| Back to top |
|
|
John Larkin
Guest
|
| Posted:
Thu Dec 08, 2005 11:44 pm Post subject:
Re: pci and caching |
|
|
On Thu, 08 Dec 2005 04:02:16 GMT, "TC" <noone@nowhere.com> wrote:
| Quote: |
"Mark McDougall" <markm@vl.com.au> wrote in message
news:4393bb75$0$23327$5a62ac22@per-qv1-newsreader-01.iinet.net.au...
Keith wrote:
That doesn't change the cacheability. Caches are a processor thing
and *NOT* under control of any PCI device.
Which begs the question, why would the PCI spec refer to something that
has nothing to do with PCI?
If a PCI memory space is marked as 'pre-fetchable' then it guarantees,
among other things, that the act of pre-fetching memory has no
side-effects. This means nothing more than the fact that it may be a
suitable candidate for caching, if the platform supports it. In this case,
a master may issue MRL (& MRM) commands.
OTOH, cache-coherency (which I assume you're hinting at) is a different
problem altogether - especially if you've got multiple bus masters
accessing PCI memory space with their own caches. However, this is a
*system* problem and (IMHO) not really any concern of the PCI bus spec
group to mandate that PCI memory is not 'cacheable' - whatever that means
in each context!
In fact, there's little discussion what-so-ever in the spec (that I can
see) about 'caches' - which is just what I would expect.
BTW I'm quite happy to be shown the error in my reasoning!
Regards,
Mark
PCI devices (peripherals) identify via Base Address Registers (BARs) the
size and type(s) of address space (IO, memory or prefecthable memory) that
they need the BIOS and/or operating system (plug and play code) to be mapped
as physical addresses on the bus. These addresses are typically accesed by
device drivers (but might also be accessed by other devices). The statement
that...
"If a PCI memory space is marked as 'pre-fetchable' then it guarantees,
among other things, that the act of pre-fetching memory has no
side-effects."
... is the best summary statement of the signifigance of 'pre-fetchable'
memory on PCI. It is used purely as a performance optimization that allows
for use of burst read transactions (specifically MRL and MRM) when accessing
that address region.
This has nothing to do with cacheing. While the original PCI specification
envisioned the ability to have cacheable memory accessed via the PCI bus
(and includes SBO# and SDONE to implement a cache coherency protocol for
PCI) I am unaware of any system or design that ever implemented this. In
subsequent specifications (i.e. PCI 2.2) it was made clear that this
functionality was being demoted and marked for removal in future
specification revisions.
Hope this helps.
TC
|
Thanks. The concensus seems to be that the Bios allocates requested
PCIbus memory resources but they are never cached. That seems to align
with my experience.
John |
|
| Back to top |
|
|
The Real Andy
Guest
|
| Posted:
Fri Dec 09, 2005 4:28 pm Post subject:
Re: pci and caching |
|
|
On Sun, 04 Dec 2005 11:35:00 -0800, John Larkin
<jjlarkin@highNOTlandTHIStechnologyPART.com> wrote:
<snip>
| Quote: | tragedies of our time. Think of how things would be if IBM had gone
with the 68K and anybody but Bill.
|
Well, we would al be using apple macs and bill gates would be poor.
There would be no dos, and no doubt all the linux guys would then hate
the origonal Mac OS. Then again, we could be really unluck and be all
stuck using OS2 blah blah blah. |
|
| Back to top |
|
|
Guest
|
| Posted:
Fri Dec 09, 2005 5:15 pm Post subject:
Re: pci and caching |
|
|
"Mark McDougall" <markm@vl.com.au> wrote in message
| Quote: | This has nothing to do with cacheing. While the original PCI specification
envisioned the ability to have cacheable memory accessed via the PCI bus
(and includes SBO# and SDONE to implement a cache coherency protocol for
PCI) I am unaware of any system or design that ever implemented this. In
subsequent specifications (i.e. PCI 2.2) it was made clear that this
functionality was being demoted and marked for removal in future
specification revisions.
|
Note that these signals are related to cache within PCI bridges and
targets that support cache. They aren't involved when the cache is
within the CPU. So you still rely on software setting up the range
of memory on the PCI device as non-cached (ie, non-CPU-cached)
even as the above mechanism is deprecated.
I hadn't thought about caching within the bridges before you
mentioned it in this thread. Ouch, I can see why it's deprecated.
There's generally good OS support for a device driver to disable
the cache within the CPU for the range of memory corresponding
to the card, but wouldn't be able to touch this in the bridge chip
very easily. Posted writes to memory mapped hardware registers
are bad enough, but cached would be a killer in cases like our
cards.
Steve |
|
| Back to top |
|
|
|
|
|
|
FAQ
Memberlist
Register
Profile
Log in to check your private messages
Log in