On Mon, 30 Apr 2007, David Miller wrote:
From: Benjamin Herrenschmidt <benh@xxxxxxxxxxxxxxxxxxx>
Date: Tue, 01 May 2007 10:00:19 +1000
Interesting - thanks for working that out. Let's keep linux-mm on cc please.
You can't elide the update_mmu_cache() call on sun4c because that will
miss some critical TLB setups which are performed there.
The sun4c TLB has two tiers of entries:
1) segment maps, these hold ptes for a range of addresses
2) ptes, mapped into segment maps
update_mmu_cache() on sun4c take care of allocating and setting
up the segment maps, so if you elide the call this never happens
and we fault forever.
Maybe we can move that logic to ptep_set_access_flags()... in fact, the
tlb flush logic should be done there too imho.
There would still be the update_mmu_cache() that we don't want on
powerpc in all cases I suppose. That can be done by having
ptep_set_access_flags() return a boolean indicating wether
update_mmu_cache() shall be called or not ...
Always doing ptep_set_access_flags() and returning a boolean like
that might be a good idea.
At present, update_mmu_cache() and lazy_mmu_prot_update() are always
called when ptep_set_access_flags() is called so why not move them into
ptep_set_access_flags() and change ptep_set_access_flags() to have an
additional boolean parameter (__update) that would when set, cause
update_mmu_cache() and lazy_mmu_prot_update() to be called.
On sun4c, an architecture specific function would be installed that
always treats the __update parameter as set at all times.
The generic function would change to somthing along the lines:
#define ptep_set_access_flags(__vma, __address, \
__ptep, __entry, __dirty, __update)
do { \
if (__update) { \
set_pte_at((__vma)->vm_mm, (__address), __ptep, __entry); \
flush_tlb_page(__vma, __address); \
update_mmu_cache(__vma, __address, __entry); \
lazy_mmu_prot_update(__entry); \
} else if (__dirty) {
flush_tlb_page(__vma, __address); \
} \
} while (0)
The code in mm/memory.c and mm/hugetlb.c and the architecture specific
versions of ptep_set_access_flags would then be changed acordingly.
Regards
Mark Fortescue.
-
To unsubscribe from this list: send the line "unsubscribe sparclinux" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
