dquot: cleanup inode allocation / freeing routines

[safe/jmp/linux-2.6] / Documentation / cachetlb.txt

diff --git a/Documentation/cachetlb.txt b/Documentation/cachetlb.txt
index 1f312a9..2b5f823 100644 (file)
--- a/Documentation/cachetlb.txt
+++ b/Documentation/cachetlb.txt
@@ -87,43 +87,20 @@ changes occur:
 
        This is used primarily during fault processing.
 
 
        This is used primarily during fault processing.
 

-5) void flush_tlb_pgtables(struct mm_struct *mm,
-                          unsigned long start, unsigned long end)
-
-   The software page tables for address space 'mm' for virtual
-   addresses in the range 'start' to 'end-1' are being torn down.
-
-   Some platforms cache the lowest level of the software page tables
-   in a linear virtually mapped array, to make TLB miss processing
-   more efficient.  On such platforms, since the TLB is caching the
-   software page table structure, it needs to be flushed when parts
-   of the software page table tree are unlinked/freed.
-
-   Sparc64 is one example of a platform which does this.
-
-   Usually, when munmap()'ing an area of user virtual address
-   space, the kernel leaves the page table parts around and just
-   marks the individual pte's as invalid.  However, if very large
-   portions of the address space are unmapped, the kernel frees up
-   those portions of the software page tables to prevent potential
-   excessive kernel memory usage caused by erratic mmap/mmunmap
-   sequences.  It is at these times that flush_tlb_pgtables will
-   be invoked.
-
-6) void update_mmu_cache(struct vm_area_struct *vma,
-                        unsigned long address, pte_t pte)
+5) void update_mmu_cache(struct vm_area_struct *vma,
+                        unsigned long address, pte_t *ptep)

 
        At the end of every page fault, this routine is invoked to
        tell the architecture specific code that a translation
 
        At the end of every page fault, this routine is invoked to
        tell the architecture specific code that a translation

-       described by "pte" now exists at virtual address "address"
-       for address space "vma->vm_mm", in the software page tables.
+       now exists at virtual address "address" for address space
+       "vma->vm_mm", in the software page tables.

 
        A port may use this information in any way it so chooses.
        For example, it could use this event to pre-load TLB
        translations for software managed TLB configurations.
        The sparc64 port currently does this.
 
 
        A port may use this information in any way it so chooses.
        For example, it could use this event to pre-load TLB
        translations for software managed TLB configurations.
        The sparc64 port currently does this.
 

-7) void tlb_migrate_finish(struct mm_struct *mm)
+6) void tlb_migrate_finish(struct mm_struct *mm)

 
        This interface is called at the end of an explicit
        process migration. This interface provides a hook
 
        This interface is called at the end of an explicit
        process migration. This interface provides a hook


@@ -133,12 +110,6 @@ changes occur:
        The ia64 sn2 platform is one example of a platform
        that uses this interface.
 
        The ia64 sn2 platform is one example of a platform
        that uses this interface.
 

-8) void lazy_mmu_prot_update(pte_t pte)
-       This interface is called whenever the protection on
-       any user PTEs change.  This interface provides a notification
-       to architecture specific code to take appropriate action.
-
-

 Next, we have the cache flushing interfaces.  In general, when Linux
 is changing an existing virtual-->physical mapping to a new value,
 the sequence will be in one of the following forms:
 Next, we have the cache flushing interfaces.  In general, when Linux
 is changing an existing virtual-->physical mapping to a new value,
 the sequence will be in one of the following forms:


@@ -179,10 +150,21 @@ Here are the routines, one by one:
        lines associated with 'mm'.
 
        This interface is used to handle whole address space
        lines associated with 'mm'.
 
        This interface is used to handle whole address space

-       page table operations such as what happens during
-       fork, exit, and exec.
+       page table operations such as what happens during exit and exec.

 
 

-2) void flush_cache_range(struct vm_area_struct *vma,
+2) void flush_cache_dup_mm(struct mm_struct *mm)
+
+       This interface flushes an entire user address space from
+       the caches.  That is, after running, there will be no cache
+       lines associated with 'mm'.
+
+       This interface is used to handle whole address space
+       page table operations such as what happens during fork.
+
+       This option is separate from flush_cache_mm to allow some
+       optimizations for VIPT caches.
+
+3) void flush_cache_range(struct vm_area_struct *vma,

                          unsigned long start, unsigned long end)
 
        Here we are flushing a specific range of (user) virtual
                          unsigned long start, unsigned long end)
 
        Here we are flushing a specific range of (user) virtual


@@ -199,7 +181,7 @@ Here are the routines, one by one:
        call flush_cache_page (see below) for each entry which may be
        modified.
 
        call flush_cache_page (see below) for each entry which may be
        modified.
 

-3) void flush_cache_page(struct vm_area_struct *vma, unsigned long addr, unsigned long pfn)
+4) void flush_cache_page(struct vm_area_struct *vma, unsigned long addr, unsigned long pfn)

 
        This time we need to remove a PAGE_SIZE sized range
        from the cache.  The 'vma' is the backing structure used by
 
        This time we need to remove a PAGE_SIZE sized range
        from the cache.  The 'vma' is the backing structure used by


@@ -220,7 +202,7 @@ Here are the routines, one by one:
 
        This is used primarily during fault processing.
 
 
        This is used primarily during fault processing.
 

-4) void flush_cache_kmaps(void)
+5) void flush_cache_kmaps(void)

 
        This routine need only be implemented if the platform utilizes
        highmem.  It will be called right before all of the kmaps
 
        This routine need only be implemented if the platform utilizes
        highmem.  It will be called right before all of the kmaps


@@ -232,7 +214,7 @@ Here are the routines, one by one:
 
        This routing should be implemented in asm/highmem.h
 
 
        This routing should be implemented in asm/highmem.h
 

-5) void flush_cache_vmap(unsigned long start, unsigned long end)
+6) void flush_cache_vmap(unsigned long start, unsigned long end)

    void flush_cache_vunmap(unsigned long start, unsigned long end)
 
        Here in these two interfaces we are flushing a specific range
    void flush_cache_vunmap(unsigned long start, unsigned long end)
 
        Here in these two interfaces we are flushing a specific range


@@ -242,7 +224,7 @@ Here are the routines, one by one:
 
        The first of these two routines is invoked after map_vm_area()
        has installed the page table entries.  The second is invoked
 
        The first of these two routines is invoked after map_vm_area()
        has installed the page table entries.  The second is invoked

-       before unmap_vm_area() deletes the page table entries.
+       before unmap_kernel_range() deletes the page table entries.

 
 There exists another whole class of cpu cache issues which currently
 require a whole different set of interfaces to handle properly.
 
 There exists another whole class of cpu cache issues which currently
 require a whole different set of interfaces to handle properly.


@@ -362,14 +344,27 @@ maps this page at its virtual address.
        likely that you will need to flush the instruction cache
        for copy_to_user_page().
 
        likely that you will need to flush the instruction cache
        for copy_to_user_page().
 

-  void flush_anon_page(struct page *page, unsigned long vmaddr)
+  void flush_anon_page(struct vm_area_struct *vma, struct page *page,
+                       unsigned long vmaddr)

        When the kernel needs to access the contents of an anonymous
        page, it calls this function (currently only
        get_user_pages()).  Note: flush_dcache_page() deliberately
        doesn't work for an anonymous page.  The default
        implementation is a nop (and should remain so for all coherent
        architectures).  For incoherent architectures, it should flush
        When the kernel needs to access the contents of an anonymous
        page, it calls this function (currently only
        get_user_pages()).  Note: flush_dcache_page() deliberately
        doesn't work for an anonymous page.  The default
        implementation is a nop (and should remain so for all coherent
        architectures).  For incoherent architectures, it should flush

-       the cache of the page at vmaddr in the current user process.
+       the cache of the page at vmaddr.
+
+  void flush_kernel_dcache_page(struct page *page)
+       When the kernel needs to modify a user page is has obtained
+       with kmap, it calls this function after all modifications are
+       complete (but before kunmapping it) to bring the underlying
+       page up to date.  It is assumed here that the user has no
+       incoherent cached copies (i.e. the original page was obtained
+       from a mechanism like get_user_pages()).  The default
+       implementation is a nop and should remain so on all coherent
+       architectures.  On incoherent architectures, this should flush
+       the kernel cache for page (using page_address(page)).
+

 
   void flush_icache_range(unsigned long start, unsigned long end)
        When the kernel stores into addresses that it will execute
 
   void flush_icache_range(unsigned long start, unsigned long end)
        When the kernel stores into addresses that it will execute


@@ -382,3 +377,27 @@ maps this page at its virtual address.
        All the functionality of flush_icache_page can be implemented in
        flush_dcache_page and update_mmu_cache. In 2.7 the hope is to
        remove this interface completely.
        All the functionality of flush_icache_page can be implemented in
        flush_dcache_page and update_mmu_cache. In 2.7 the hope is to
        remove this interface completely.

+
+The final category of APIs is for I/O to deliberately aliased address
+ranges inside the kernel.  Such aliases are set up by use of the
+vmap/vmalloc API.  Since kernel I/O goes via physical pages, the I/O
+subsystem assumes that the user mapping and kernel offset mapping are
+the only aliases.  This isn't true for vmap aliases, so anything in
+the kernel trying to do I/O to vmap areas must manually manage
+coherency.  It must do this by flushing the vmap range before doing
+I/O and invalidating it after the I/O returns.
+
+  void flush_kernel_vmap_range(void *vaddr, int size)
+       flushes the kernel cache for a given virtual address range in
+       the vmap area.  This is to make sure that any data the kernel
+       modified in the vmap range is made visible to the physical
+       page.  The design is to make this area safe to perform I/O on.
+       Note that this API does *not* also flush the offset map alias
+       of the area.
+
+  void invalidate_kernel_vmap_range(void *vaddr, int size) invalidates
+       the cache for a given virtual address range in the vmap area
+       which prevents the processor from making the cache stale by
+       speculatively reading data while the I/O was occurring to the
+       physical pages.  This is only necessary for data reads into the
+       vmap area.