Messages in this thread |  | | | Subject | update_mmu_cache(): fault or not fault ? | | From | Benjamin Herrenschmidt <> | | Date | Mon, 26 Sep 2005 16:22:05 +1000 |
Hi !
I been toying with using update_mmu_cache() to actually fill the TLB entry directly when taking a fault on some PPC CPUs with software TLB reload (among other optims I have in mind). Most of CPUs with software TLB reload currently take double TLB faults on linux page faults.
The problem is that want to only ever do that kind of hw TLB pre-fill when update_mmu_cache() is called as the result an actual fault. However, for some reasons that I'm not 100% sure about (*) update_mmu_cache() is called from other places, typically in mm/fremap.c which aren't directly results of faults.
So I suggest adding an argument to it "int is_fault", that would basically be '1' on all the call sites in mm/memory.c and '0' in all the call sites in mm/fremap.c.
Any objection, comment, whatever, before I come up with a patch adding it to all archs ?
Ben.
(*) I suspect because update_mmu_cache() has historically been hijacked to do the icache/dcache sync on some architecture, and thus was added to all call sites that can populate a PTE out of the blue, though it's a bit dodgy that it's not called in mremap(), thus people with hw execute permission using that trick should be careful... but then, if you have execute permission, you probably don't need that trick. This is what ppc32 and ppc64 old older CPUs do, in an SMP racy way even ;) But that's a different discussion and I'll have to fix it some day.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |