linux-origin
[Top] [All Lists]

Re: update_mmu_cache

To: ralf@xxxxxxxxxxx (Ralf Baechle)
Subject: Re: update_mmu_cache
From: Kanoj Sarcar <kanoj@xxxxxxxxxxxxxxxxxxx>
Date: Mon, 24 Jul 2000 09:40:12 -0700 (PDT)
Cc: linux-origin@xxxxxxxxxxx
In-reply-to: <20000724004409.B2678@xxxxxxxxxxxxxxxx> from "Ralf Baechle" at Jul 24, 2000 12:44:09 AM
Sender: owner-linux-origin@xxxxxxxxxxx
> 
> Kanoj,
> 
> we've got one left problem with my new implementation of flush_icache_page().

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.

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).

> This function receives a vma ptr and a struct page ptr as arguments.
> That means we don't know the virtual address of the userspace mapping
> when flushing.  We could either pass the virtual address as a new

Don't know the answer yet ... working on it ...

> additional argument or could move the icache flushing stuff into
> update_mmu_cache() which already has all these arguments.  flush_icache_page()
> doesn't properly cover all code paths also, see for example this
> fragment of handle_pte_fault:


> 
> [...]
> tatic inline int handle_pte_fault(struct mm_struct *mm,
>         struct vm_area_struct * vma, unsigned long address,
>         int write_access, pte_t * pte)
> {
>         pte_t entry;
> 
>         entry = *pte;
>         if (!pte_present(entry)) {
>                 if (pte_none(entry))
>                         return do_no_page(mm, vma, address, write_access, 
> pte);
>                 return do_swap_page(mm, vma, address, pte, 
> pte_to_swp_entry(entry), write_access);
>         }
> [...]
> 
> which could bring a codepage in without properly flushing the icache.

Don't see that. Both of do_no_page and do_swap_page have flush_icache_pages
in them, what else might get thru?

> 
> 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.

Kanoj

> 
> What do you think?
> 
>   Ralf
> 


<Prev in Thread] Current Thread [Next in Thread>