Thread (18 messages) 18 messages, 4 authors, 2009-03-31

Re: [PATCH] ucc_geth: Rework the TX logic.

From: Joakim Tjernlund <hidden>
Date: 2009-03-31 09:07:40
Also in: linuxppc-dev

Scott Wood [off-list ref] wrote on 30/03/2009 21:32:23:
Joakim Tjernlund wrote:
quoted
quoted
different since descriptors are in MURAM which is ioremap()ed -- 
though 
quoted
quoted
switching to a cacheable mapping with barriers should be a 
performance 
quoted
quoted
improvement.
I always thought that MURAM was very fast. The whole reason to have 
BDs in
quoted
MURAM is that it is faster than normal RAM, at least that is what I 
thought.
Yeah, on second thought it probably wouldn't be worth it.  There's also 
the question of under what circumstances the QE's MURAM accesses will be 
cache-coherent.
I am a bit confused, what isn't worth it? Currently MURAM isn't used by 
ucc_geth, but
it is easy to change. Swap MEM_PART_SYSTEM to MEM_PART_MURAM, however, 
just
tried that and the driver stopped working. I known this worked earlier 
because
I tried it and I even think I sent a patch to Leo.

What choices do we have, I see three:

1) MEM_PART_SYSTEM, as today.
2) MEM_PART_MURAM. I guess this should be uncacheable memory?
3) as gianfar, dma_alloc_coherent(). I presume this is uncacheable memory?

My guess would be 2 or 3. Do they have the same synchronization
sematics?
As for the CPU not reordering guarded+cache inhibited accesses, that 
initially seemed to be true for the new arch stuff (book3e/book3s, but 
not really, see below), but the classic arch documentation only 
guarantees stores to such regions to be in-order (and the 
explicitly-specified operation of eieio on I+G accesses wouldn't make 
much sense if they were already guaranteed to be in-order).

Then I looked at the EREF to see what older book E documents had to say 
on the issue, and it suggests that when the architecture document says 
"out of order", it really means "speculative" (and reading the arch 
doc's definition of "out of order" seems to confirm this -- redefining 
terms is bad, m'kay?).  So it seems that the simple answer is no, 
guarded storage is not guaranteed to be in order, unless the only thing 
that can cause an out-of-order access is speculative execution.
Very informative, thanks.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help