Re: [PATCH]: Handling spurious page fault for hugetlb region for2.6.14-rc4-git5

[Rohit Seth]

On Wed, 2005-10-19 at 13:53 -0700, Linus Torvalds wrote:
> 

> The fact is, the VM layer is designed for systems that do not cache 
> not-present entries in their TLB. See for example the end of do_no_page() 
> in mm/memory.c:
> 
> 	        /* no need to invalidate: a not-present page shouldn't be cached */
> 	        update_mmu_cache(vma, address, entry);
> 	        lazy_mmu_prot_update(entry);
> 	        spin_unlock(&mm->page_table_lock);
> 	out:
> 	        return ret;
> 
> which _allows_ for hardware that caches not-present pages, but the 
> architecture needs to catch them in the "update_mmu_cache()".
> 

I agree that one way would be to flush the TLB as part of
update_mmu_cache.  But that would result in too many extra global
flushes.  Instead in IA-64, we wait till fault time to do local flushes
whenever needed.

> If ia64 caches non-present TLB entries, then that would seem to be a bug 
> in the Linux ia64 port:
> 
>  - include/asm-ia64/pgtable.h:
> 	#define update_mmu_cache(vma, address, pte) do { } while (0)
> 
> (Of course, you can and maybe do handle it differently: you can also 
> decide to just take the TLB fault, and flush the TLB at fault time in your 
> handler. I don't see that either on ia64, though. Although I didn't look 
> into any of the asm code, so maybe it's hidden somewhere there).
> 

The low level page_not_present vector (asm code) flushes the stale entry
that could be sitting in TLB resulting in current page fault.


But anyways now there is another scenario that Hugh has pointed out in
the last mail that needs to be taken care of too...

-rohit

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/