[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: working xfree86 4.1.0?

On Sat, Jan 19, 2002 at 01:04:07AM +0100, Kars de Jong wrote:

> I'll dig up my patch to see if I can get it working again, but I remember it 
> being a bit kludgy because we have no equivalent of ppc_flush_icache() on 
> m68k. There is __cache_flush() in libgcc (or was it libc?) but its API is 
> quite different. And instead of flushing a cache line (?) for each relocated 
> address (which is what PPC seems to do) we might be better off flushing the 
> cache for the entire relocated section after it's been relocated (I think 
> __cache_flush() wants a start address and a length argument).
> Or maybe we should use the m68k cacheflush syscall() instead.

the cacheflush syscall has been changed to work "reasonably"(*), ie if you
tell it to flush more than 3 pages using cache line flush it will use page
flush instead. Of course if the program does 2000 little lineflushes
that won't help, you get terrible performance.
You can't flush caches section-wise on m68k but you can do a full cache 
flush - sys_cacheflush does it if you specifiy size more than 10 pagesizes
(you still need to supply a legal address for this).

My 060 manual lists these times:
	CPUSHL  <= 26 
	CPUSHP  <= 2838
	CPUSHA  == 5394

for a single syscall add ~300 cycles (060 again). The full flush has the
additional cost that everything has to be fetched again into cache and 
interrupts are disabled for 5400 clock cycles (would it be worth 
changing that?).
So I would say if you flush more than 15-20 entries go for the full flush.

> Debugging the modules is a real pain without the XFree86 gdb patch by the 
> way, is there anyone who built a gdb with that patch for m68k?

I have gdb 5.0 though coredump reading doesn't work yet.


(*) someone got better figures what is reasonable?

Reply to: