1. 22 3月, 2006 1 次提交
    • D
      [PATCH] hugepage: Fix hugepage logic in free_pgtables() · 9da61aef
      David Gibson 提交于
      free_pgtables() has special logic to call hugetlb_free_pgd_range() instead
      of the normal free_pgd_range() on hugepage VMAs.  However, the test it uses
      to do so is incorrect: it calls is_hugepage_only_range on a hugepage sized
      range at the start of the vma.  is_hugepage_only_range() will return true
      if the given range has any intersection with a hugepage address region, and
      in this case the given region need not be hugepage aligned.  So, for
      example, this test can return true if called on, say, a 4k VMA immediately
      preceding a (nicely aligned) hugepage VMA.
      
      At present we get away with this because the powerpc version of
      hugetlb_free_pgd_range() is just a call to free_pgd_range().  On ia64 (the
      only other arch with a non-trivial is_hugepage_only_range()) we get away
      with it for a different reason; the hugepage area is not contiguous with
      the rest of the user address space, and VMAs are not permitted in between,
      so the test can't return a false positive there.
      
      Nonetheless this should be fixed.  We do that in the patch below by
      replacing the is_hugepage_only_range() test with an explicit test of the
      VMA using is_vm_hugetlb_page().
      
      This in turn changes behaviour for platforms where is_hugepage_only_range()
      returns false always (everything except powerpc and ia64).  We address this
      by ensuring that hugetlb_free_pgd_range() is defined to be identical to
      free_pgd_range() (instead of a no-op) on everything except ia64.  Even so,
      it will prevent some otherwise possible coalescing of calls down to
      free_pgd_range().  Since this only happens for hugepage VMAs, removing this
      small optimization seems unlikely to cause any trouble.
      
      This patch causes no regressions on the libhugetlbfs testsuite - ppc64
      POWER5 (8-way), ppc64 G5 (2-way) and i386 Pentium M (UP).
      Signed-off-by: NDavid Gibson <dwg@au1.ibm.com>
      Cc: William Lee Irwin III <wli@holomorphy.com>
      Acked-by: NHugh Dickins <hugh@veritas.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      9da61aef
  2. 30 11月, 2005 1 次提交
  3. 12 11月, 2005 1 次提交
    • R
      [IA64] 4-level page tables · 837cd0bd
      Robin Holt 提交于
      This patch introduces 4-level page tables to ia64.  I have run
      some benchmarks and found nothing interesting.  Performance has
      consistently fallen within the noise range.
      
      It also introduces a config option (setting the default to 3
      levels).  The config option prevents having 4 level page
      tables with 64k base page size.
      Signed-off-by: NRobin Holt <holt@sgi.com>
      Signed-off-by: NTony Luck <tony.luck@intel.com>
      837cd0bd
  4. 01 11月, 2005 1 次提交
  5. 05 10月, 2005 1 次提交
  6. 25 8月, 2005 2 次提交
    • G
      [IA64] clean up sn2 region definitions · 1b66776d
      Greg Edwards 提交于
      Clean up some duplicate region definitions in sn2 code.
      Signed-off-by: NGreg Edwards <edwardsg@sgi.com>
      Signed-off-by: NTony Luck <tony.luck@intel.com>
      1b66776d
    • P
      [IA64] Rationalise Region Definitions · 0a41e250
      Peter Chubb 提交于
      Currently, region numbers are defined in several files, with several 
      names.  For example, we have REGION_KERNEL in asm/page.h and 
      RGN_KERNEL in pgtable.h 
       
      We also have address definitions that should depend on the 
      RGN_XXX macros, but are currently just long constants. 
       
      The following patch reorganises all the definitions so that they have 
      the same form (RGN_XXX), are in one place, and that addresses that 
      depend on RGN_XXX are derived from them. 
      
      (This is a necessary but not sufficient patch to allow UML-like 
      operation on IA64). 
      
      Thanks to David Mosberger for catching the change I missed in mmu_context.h.
       
      Signed-off-by: Peter Chubb <peterc@gelato.unsw.edu.au> 
      Signed-off-by: NTony Luck <tony.luck@intel.com>
      0a41e250
  7. 20 4月, 2005 1 次提交
    • H
      [PATCH] freepgt: hugetlb_free_pgd_range · 3bf5ee95
      Hugh Dickins 提交于
      ia64 and ppc64 had hugetlb_free_pgtables functions which were no longer being
      called, and it wasn't obvious what to do about them.
      
      The ppc64 case turns out to be easy: the associated tables are noted elsewhere
      and freed later, safe to either skip its hugetlb areas or go through the
      motions of freeing nothing.  Since ia64 does need a special case, restore to
      ppc64 the special case of skipping them.
      
      The ia64 hugetlb case has been broken since pgd_addr_end went in, though it
      probably appeared to work okay if you just had one such area; in fact it's
      been broken much longer if you consider a long munmap spanning from another
      region into the hugetlb region.
      
      In the ia64 hugetlb region, more virtual address bits are available than in
      the other regions, yet the page tables are structured the same way: the page
      at the bottom is larger.  Here we need to scale down each addr before passing
      it to the standard free_pgd_range.  Was about to write a hugely_scaled_down
      macro, but found htlbpage_to_page already exists for just this purpose.  Fixed
      off-by-one in ia64 is_hugepage_only_range.
      
      Uninline free_pgd_range to make it available to ia64.  Make sure the
      vma-gathering loop in free_pgtables cannot join a hugepage_only_range to any
      other (safe to join huges?  probably but don't bother).
      Signed-off-by: NHugh Dickins <hugh@veritas.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      3bf5ee95
  8. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      
      Let it rip!
      1da177e4