On Mon, Jul 24, 2000 at 09:40:12AM -0700, Kanoj Sarcar wrote:
> Could you send the logic of your optimized cache flushing? As I mentioned
> before, getting that right first is more important than doing the coding ...
> Btw, the generic cpu type in your patch can come in later, after we have
> made sure the r10k works fine, instead of piling up multiple changes into
> one patch.
The generic cpu type was a side product. Since most of the R10k cache
functions are empty functions now the obvious final step was to inline
those into the callers also getting rid of the overhead of the function
pointers. The generic cpu type is implemented only exactly to the degree
that is necessary to achieve this.
> I did some coding too, and am currently debugging it. My logic is this:
> flush_icache_page will writeback-invalidate dcache, invalidate icache.
> flush_icache_range will writeback-invalidate dcache ... additionally, if
> flush_icache_range is invoked on a kernel address (module loading), it
> will also invalidate icache (since it can not rely on flush_icache_page
> having done the icache flush).
Sounds good.
Under the assumption flush_icache_range'd only be called for modules I left
it out of my optimizations, it's being called very rarely, so the whole
job of making i & d cache coherent is left to flush_icache_page.
> Don't see that. Both of do_no_page and do_swap_page have flush_icache_pages
> in them, what else might get thru?
Sorry, I had tomatoes on my eyes. The only case the goes through is
do_anonymous_page() but that one doesn't make sense for code, so no need
to flush caches.
> > I'm not sure why things are as they are but afair flush_icache_page() was
> > added due to some sparc problem. So I see three approaches now:
> >
> > - sprinkle some more flush_icache_pages over generic mm and add a third
> > vaddr argument.
> > - move icache flushing into update_mmu_cache.
> > - handle the cache flushing thing in do_page_fault in fault.c.
>
> All of these are possibilities. As I said before, before we decide which
> is the best one, we need to decide exactly when we need to flush caches.
> First, we need to see if the current (icache flush) hooks will suffice
> (this is what I am trying and debugging currently). If not, we need to
> move the flushes into code that has all the information, or get more
> information added into the generic hooks.
I've now choosen the last possibility, it results in the most compact code.
Ralf
|