Re: [parisc-linux] 2.4.0-test6 lack of speed

[Matthew Wilcox <matthew@wil.cx>]

On Wed, Aug 23, 2000 at 05:23:20PM +0100, Richard Hirst wrote:
> It looks to me like all calls to flush_cache_range() are passed a user
> virtual address, except for those calls from arch/parisc/kernel/pci-dma.c
> where we pass kernel virtual addresses.

agreed.

> So perhaps flush_cache_range() should generate FIC/FICE/FDC/FDCE
> instructions with a space register of %sr3, and pci-dma.c should
> use some other method of flushing memory.
> 
> I was looking at the difference between FDC and FDCE; it seems FDC
> does address translation and FDCE does not, so should we use FDC
> really?  flush_cache_range() currently uses FDCE/FICE.

we should stop using FICE/FDCE/PDTLBE/PITLBE except in the `flush
entire cache' routines.  the definitions should be moved from cache.h
to cache.c.  No-one else should be given the opportunaity to use them.
They are too undefined.

> Helge Deller wrote some code in drivers/net/lasi_82596.c that plays
> with %sr1 and uses FDC, FIC, PDC, SYNC, and SYNCDMA.
> 
> Can someone tell me why include/asm/cache.h has no space register
> specified on fdce():
> 
> > #define fdce(addr) asm volatile("fdce 0(%0)" : : "r" (addr))
> > #define fice(addr) asm volatile("fice 0(%%sr1,%0)" : : "r" (addr))
> > 
> > #define pdtlbe(addr) asm volatile("pdtlbe 0(%%sr1,%0)" : : "r" (addr))
> > #define pitlbe(addr) asm volatile("pitlbe 0(%%sr1,%0)" : : "r" (addr))

My attempt at fixing this in a sane manner led me to create:

#define user_fdc(addr) asm volatile("fdc 0(%%sr3,%0)" : : "r" (addr))
(...)

and

#define kernel_fdc(addr) asm volatile("fdc 0(%%sr0,%0)" : : "r" (addr))
(...)

however, the resulting kernel wouldn't boot.  So let's take this a
step at a time and see how far we can go towards eliminating the *E
variants.  I've written a little rant on this suject which you can find
in linux-2.3/Documentation/parisc/mm.  feel free to ignore it if you want.

> ps. as you can see, I am learning as I go here, so all hints and
> clues are gratefully accepted!

Likewise!  BTW, I hear davem wrote a doc about this which is in
-test8-pre1 which may help somewhat.

-- 
Revolutions do not require corporate support.