user/sven/linux.git/include/asm-frv/pgtable.h, branch ipvs/droutbytes

mm: introduce pte_special pte bit

2008-04-28T15:58:23Z

s390 for one, cannot implement VM_MIXEDMAP with pfn_valid, due to their memory model (which is more dynamic than most). Instead, they had proposed to implement it with an additional path through vm_normal_page(), using a bit in the pte to determine whether or not the page should be refcounted: vm_normal_page() { ... if (unlikely(vma->vm_flags & (VM_PFNMAP|VM_MIXEDMAP))) { if (vma->vm_flags & VM_MIXEDMAP) { #ifdef s390 if (!mixedmap_refcount_pte(pte)) return NULL; #else if (!pfn_valid(pfn)) return NULL; #endif goto out; } ... } This is fine, however if we are allowed to use a bit in the pte to determine refcountedness, we can use that to _completely_ replace all the vma based schemes. So instead of adding more cases to the already complex vma-based scheme, we can have a clearly seperate and simple pte-based scheme (and get slightly better code generation in the process): vm_normal_page() { #ifdef s390 if (!mixedmap_refcount_pte(pte)) return NULL; return pte_page(pte); #else ... #endif } And finally, we may rather make this concept usable by any architecture rather than making it s390 only, so implement a new type of pte state for this. Unfortunately the old vma based code must stay, because some architectures may not be able to spare pte bits. This makes vm_normal_page a little bit more ugly than we would like, but the 2 cases are clearly seperate. So introduce a pte_special pte state, and use it in mm/memory.c. It is currently a noop for all architectures, so this doesn't actually result in any compiled code changes to mm/memory.o. BTW: I haven't put vm_normal_page() into arch code as-per an earlier suggestion. The reason is that, regardless of where vm_normal_page is actually implemented, the *abstraction* is still exactly the same. Also, while it depends on whether the architecture has pte_special or not, that is the only two possible cases, and it really isn't an arch specific function -- the role of the arch code should be to provide primitive functions and accessors with which to build the core code; pte_special does that. We do not want architectures to know or care about vm_normal_page itself, and we definitely don't want them being able to invent something new there out of sight of mm/ code. If we made vm_normal_page an arch function, then we have to make vm_insert_mixed (next patch) an arch function too. So I don't think moving it to arch code fundamentally improves any abstractions, while it does practically make the code more difficult to follow, for both mm and arch developers, and easier to misuse. [akpm@linux-foundation.org: build fix] Signed-off-by: Nick Piggin Acked-by: Carsten Otte Cc: Jared Hulbert Cc: Martin Schwidefsky Cc: Heiko Carstens Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

FRV: Handle update_mmu_cache() being called when current->mm is NULL [try #2]

2008-04-10T20:41:28Z

Handle update_mmu_cache() being called when current->mm is NULL. We cache static TLB mappings for the current page table in DAMPR4 and DAMPR5 on the theory that the next data lookup is likely to be in the same general region, and thus is likely to be mapped by the same page table. However, we can't get this information if we can't access the appropriate mm_struct. If current->mm is NULL, we just clear the cache in the knowledge that the TLB miss handlers will load it. Signed-off-by: David Howells Signed-off-by: Linus Torvalds

add mm argument to pte/pmd/pud/pgd_free

2008-02-05T17:44:18Z

(with Martin Schwidefsky ) The pgd/pud/pmd/pte page table allocation functions get a mm_struct pointer as first argument. The free functions do not get the mm_struct argument. This is 1) asymmetrical and 2) to do mm related page table allocations the mm argument is needed on the free function as well. [kamalesh@linux.vnet.ibm.com: i386 fix] [akpm@linux-foundation.org: coding-syle fixes] Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Martin Schwidefsky Cc: Signed-off-by: Kamalesh Babulal Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

move frv docs one level up

2008-02-03T13:54:28Z

My first guess for "fujitsu" was it might be related to the fujitsu-laptop.c driver... Move the frv directory one level up since frv is the name of the architecture in the Linux kernel. Signed-off-by: Adrian Bunk

mm: remove ptep_test_and_clear_dirty and ptep_clear_flush_dirty

2007-07-17T17:22:59Z

Nobody is using ptep_test_and_clear_dirty and ptep_clear_flush_dirty. Remove the functions from all architectures. Signed-off-by: Martin Schwidefsky Cc: Hugh Dickins Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

page table handling cleanup

2007-07-16T16:05:36Z

Kill pte_rdprotect(), pte_exprotect(), pte_mkread(), pte_mkexec(), pte_read(), pte_exec(), and pte_user() except where arch-specific code is making use of them. Signed-off-by: Jan Beulich Cc: Andi Kleen Cc: Christoph Hellwig Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

frv: fix fallout from "remove sched.h from mm.h" patch

2007-07-01T19:29:44Z

/home/rpjday/AMD/k/topics/0_hi/hi1.c:15: error: dereferencing pointer to incomplete type /home/rpjday/AMD/k/topics/0_hi/hi1.c:16: error: dereferencing pointer to incomplete type Signed-off-by: Alexey Dobriyan Cc: David Howells Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

Clean up mostly unused IOSPACE macros

2007-05-08T18:15:13Z

Most architectures defined three macros, MK_IOSPACE_PFN(), GET_IOSPACE() and GET_PFN() in pgtable.h. However, the only callers of any of these macros are in Sparc specific code, either in arch/sparc, arch/sparc64 or drivers/sbus. This patch removes the redundant macros from all architectures except sparc and sparc64. Signed-off-by: David Gibson Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[PATCH] FRV: Add some missng lazy MMU hooks for NOMMU mode

2007-03-01T22:53:36Z

Add some missing lazy MMU hooks for NOMMU mode. Signed-off-by: David Howells Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[PATCH] paravirt: remove set pte atomic

2006-10-01T07:39:34Z

Now that ptep_establish has a definition in PAE i386 3-level paging code, the only paging model which is insane enough to have multi-word hardware PTEs which are not efficient to set atomically, we can remove the ghost of set_pte_atomic from other architectures which falesly duplicated it, and remove all knowledge of it from the generic pgtable code. set_pte_atomic is now a private pte operator which is specific to i386 Signed-off-by: Zachary Amsden Cc: Rusty Russell Cc: Jeremy Fitzhardinge Cc: Andi Kleen Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds