1. 30 10月, 2005 1 次提交
    • H
      [PATCH] mm: init_mm without ptlock · 872fec16
      Hugh Dickins 提交于
      First step in pushing down the page_table_lock.  init_mm.page_table_lock has
      been used throughout the architectures (usually for ioremap): not to serialize
      kernel address space allocation (that's usually vmlist_lock), but because
      pud_alloc,pmd_alloc,pte_alloc_kernel expect caller holds it.
      
      Reverse that: don't lock or unlock init_mm.page_table_lock in any of the
      architectures; instead rely on pud_alloc,pmd_alloc,pte_alloc_kernel to take
      and drop it when allocating a new one, to check lest a racing task already
      did.  Similarly no page_table_lock in vmalloc's map_vm_area.
      
      Some temporary ugliness in __pud_alloc and __pmd_alloc: since they also handle
      user mms, which are converted only by a later patch, for now they have to lock
      differently according to whether or not it's init_mm.
      
      If sources get muddled, there's a danger that an arch source taking
      init_mm.page_table_lock will be mixed with common source also taking it (or
      neither take it).  So break the rules and make another change, which should
      break the build for such a mismatch: remove the redundant mm arg from
      pte_alloc_kernel (ppc64 scrapped its distinct ioremap_mm in 2.6.13).
      
      Exceptions: arm26 used pte_alloc_kernel on user mm, now pte_alloc_map; ia64
      used pte_alloc_map on init_mm, now pte_alloc_kernel; parisc had bad args to
      pmd_alloc and pte_alloc_kernel in unused USE_HPPA_IOREMAP code; ppc64
      map_io_page forgot to unlock on failure; ppc mmu_mapin_ram and ppc64 im_free
      took page_table_lock for no good reason.
      Signed-off-by: NHugh Dickins <hugh@veritas.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      872fec16
  2. 22 10月, 2005 1 次提交
    • B
      [PATCH] ppc64: Fix pages marked dirty abusively · 5d965515
      Benjamin Herrenschmidt 提交于
      While working on 64K pages, I found this little buglet in our
      update_mmu_cache() implementation.
      
      The code calls __hash_page() passing it an "access" parameter (the type
      of access that triggers the hash) containing the bits _PAGE_RW and
      _PAGE_USER of the linux PTE.  The latter is useless in this case and the
      former is wrong.  In fact, if we have a writeable PTE and we pass
      _PAGE_RW to hash_page(), it will set _PAGE_DIRTY (since we track dirty
      that way, by hash faulting !dirty) which is not what we want.
      
      In fact, the correct fix is to always pass 0. That means that only
      read-only or already dirty read write PTEs will be preloaded. The
      (hopefully rare) case of a non dirty read write PTE can't be preloaded
      this way, it will have to fault in hash_page on the actual access.
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      5d965515
  3. 09 9月, 2005 1 次提交
  4. 06 9月, 2005 1 次提交
  5. 05 9月, 2005 1 次提交
    • B
      [PATCH] SPARSEMEM EXTREME · 802f192e
      Bob Picco 提交于
      A new option for SPARSEMEM is ARCH_SPARSEMEM_EXTREME.  Architecture
      platforms with a very sparse physical address space would likely want to
      select this option.  For those architecture platforms that don't select the
      option, the code generated is equivalent to SPARSEMEM currently in -mm.
      I'll be posting a patch on ia64 ml which uses this new SPARSEMEM feature.
      
      ARCH_SPARSEMEM_EXTREME makes mem_section a one dimensional array of
      pointers to mem_sections.  This two level layout scheme is able to achieve
      smaller memory requirements for SPARSEMEM with the tradeoff of an
      additional shift and load when fetching the memory section.  The current
      SPARSEMEM -mm implementation is a one dimensional array of mem_sections
      which is the default SPARSEMEM configuration.  The patch attempts isolates
      the implementation details of the physical layout of the sparsemem section
      array.
      
      ARCH_SPARSEMEM_EXTREME depends on 64BIT and is by default boolean false.
      
      I've boot tested under aim load ia64 configured for ARCH_SPARSEMEM_EXTREME.
       I've also boot tested a 4 way Opteron machine with !ARCH_SPARSEMEM_EXTREME
      and tested with aim.
      Signed-off-by: NAndy Whitcroft <apw@shadowen.org>
      Signed-off-by: NBob Picco <bob.picco@hp.com>
      Signed-off-by: NDave Hansen <haveblue@us.ibm.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      802f192e
  6. 29 8月, 2005 4 次提交
    • M
      [PATCH] ppc64: Remove physbase from the lmb_property struct · 180379dc
      Michael Ellerman 提交于
      We no longer need the lmb code to know about abs and phys addresses, so
      remove the physbase variable from the lmb_property struct.
      Signed-off-by: NMichael Ellerman <michael@ellerman.id.au>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      180379dc
    • M
      [PATCH] ppc64: Remove redundant abs_to_phys() macro · e88bcd1b
      Michael Ellerman 提交于
      abs_to_phys() is a macro that turns out to do nothing, and also has the
      unfortunate property that it's not the inverse of phys_to_abs() on iSeries.
      
      The following is for my benefit as much as everyone else.
      
      With CONFIG_MSCHUNKS enabled, the lmb code is changed such that it keeps
      a physbase variable for each lmb region. This is used to take the possibly
      discontiguous lmb regions and present them as a contiguous address space
      beginning from zero.
      
      In this context each lmb region's base address is its "absolute" base
      address, and its physbase is it's "physical" address (from Linux's point of
      view). The abs_to_phys() macro does the mapping from "absolute" to "physical".
      
      Note: This is not related to the iSeries mapping of physical to absolute
      (ie. Hypervisor) addresses which is maintained with the msChunks structure.
      And the msChunks structure is not controlled via CONFIG_MSCHUNKS.
      
      Once upon a time you could compile for non-iSeries with CONFIG_MSCHUNKS
      enabled. But these days CONFIG_MSCHUNKS depends on CONFIG_PPC_ISERIES, so
      for non-iSeries code abs_to_phys() is a no-op.
      
      On iSeries we always have one lmb region which spans from 0 to
      systemcfg->physicalMemorySize (arch/ppc64/kernel/iSeries_setup.c line 383).
      This region has a base (ie. absolute) address of 0, and a physbase address
      of 0 (as calculated in lmb_analyze() (arch/ppc64/kernel/lmb.c line 144)).
      
      On iSeries, abs_to_phys(aa) is defined as lmb_abs_to_phys(aa), which finds
      the lmb region containing aa (and there's only one, ie. 0), and then does:
      
       return lmb.memory.region[0].physbase + (aa - lmb.memory.region[0].base)
      
      physbase == base == 0, so you're left with "return aa".
      
      So remove abs_to_phys(), and lmb_abs_to_phys() which is the implementation
      of abs_to_phys() for iSeries.
      Signed-off-by: NMichael Ellerman <michael@ellerman.id.au>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      e88bcd1b
    • S
      [PATCH] ppc64: move iSeries vio iommu init · 8c65b5c9
      Stephen Rothwell 提交于
      Since the iSeries vio iommu tables cannot be used until after the vio bus has
      been initialised, move the initialisation of the tables to there.
      Signed-off-by: NStephen Rothwell <sfr@canb.auug.org.au>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      8c65b5c9
    • D
      [PATCH] Four level pagetables for ppc64 · e28f7faf
      David Gibson 提交于
      Implement 4-level pagetables for ppc64
      
      This patch implements full four-level page tables for ppc64, thereby
      extending the usable user address range to 44 bits (16T).
      
      The patch uses a full page for the tables at the bottom and top level,
      and a quarter page for the intermediate levels.  It uses full 64-bit
      pointers at every level, thus also increasing the addressable range of
      physical memory.  This patch also tweaks the VSID allocation to allow
      matching range for user addresses (this halves the number of available
      contexts) and adds some #if and BUILD_BUG sanity checks.
      Signed-off-by: NDavid Gibson <dwg@au1.ibm.com>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      e28f7faf
  7. 14 7月, 2005 1 次提交
  8. 24 6月, 2005 2 次提交
  9. 22 6月, 2005 1 次提交
    • D
      [PATCH] ppc64: Abolish ioremap_mm · 20cee16c
      David Gibson 提交于
      Currently ppc64 has two mm_structs for the kernel, init_mm and also
      ioremap_mm.  The latter really isn't necessary: this patch abolishes it,
      instead restricting vmallocs to the lower 1TB of the init_mm's range and
      placing io mappings in the upper 1TB.  This simplifies the code in a number
      of places and eliminates an unecessary set of pagetables.  It also tweaks
      the unmap/free path a little, allowing us to remove the unmap_im_area() set
      of page table walkers, replacing them with unmap_vm_area().
      Signed-off-by: NDavid Gibson <dwg@au1.ibm.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      20cee16c
  10. 06 5月, 2005 2 次提交
  11. 01 5月, 2005 1 次提交
  12. 17 4月, 2005 2 次提交
    • B
      [PATCH] ppc64: Fix semantics of __ioremap · dfbacdc1
      Benjamin Herrenschmidt 提交于
      This patch fixes ppc64 __ioremap() so that it stops adding implicitely
      _PAGE_GUARDED when the cache is not writeback, and instead, let the callers
      provide the flag they want here.  This allows things like framebuffers to
      explicitely request a non-cacheable and non-guarded mapping which is more
      efficient for that type of memory without side effects.  The patch also
      fixes all current callers to add _PAGE_GUARDED except btext, which is fine
      without it.
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      dfbacdc1
    • 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