Re: [linuxsh-dev] Re: a 2.5.69 local patch

[Paul M. <le...@li...>]

On Thu, May 08, 2003 at 12:53:16PM +0900, SUGIOKA Toshinobu wrote:
> flush_icache_range(unsigned long start, unsigned long end) in HEAD doesn't work anyway.
> This function is used in fs/binfmt_elf.c and requires flush range from
> start to end, but in HEAD version, it flushes only 1 line (32byte).
> I think it's better to flush whole i-cache because the range may be very large.

Okay, agreed. In the future, I think we may want to do slightly more
intelligent bounds checking to verify whether flushing the entire icache
is faster or not, but that'll require a bit of careful profiling. (Such
as only flushing parts when the range is small and flushing the whole
thing when its over a predetermined threshold).

> Well, I know that fixups. but...
> (1) On older SH-4 CPUs, current 2.4 branch works well. These functions are oprimized for
>     these CPUs, but they assumes direct mapped cache so we can't use on 2-way cache.
>     That fixups simply extends address range for pre-loading to flush d-cache.
>     I think this is a bit dangerous because LRU bit may not work always for this purpose.
>     And anyway, there is more efficient method to flush 2-way cache.
> 
> (2) On new type CPUs that have 2-way cache system, we have no restriction to access
>     operand cache address array, so we can flush d-cache by clearing this array without
>     performance penalty.
> 
Okay, performance is what I was primarily concerned with, the old method
for flushing out the direct-mapped will certainly suffer with 2-way, and
even moreso with 4-way. With no access restriction on the OC addr array,
that definitely seems like the optimal way to go.

Time to re-examine the SH-2 caches..

> (3) I don't like the code like this, because it is hard to maintain.
> +	mov.l	@(56,r6),r1        ! cpu_data->dcache.ways
> 
Agreed. However, this is hardly isolated, entry.S does quite a bit of
this as well.

> (4) We don't need to consider multi-way in functions that use flush_cache_4096(),
>     ASSOC bit works for that.
>     flush_dcache_page() and __flush_cache_page() in 2.4 branch seems work without any change.
> 
Okay, I hadn't looked into that, but that's certainly good. It'll help
with performance.

Feel free to check this stuff in then, things appear to still work on
the stock 7750 with these changes.. and this should finally put an end
to the 7750R/7751R nonsense.