You need to sign in or sign up before continuing.
  1. 09 1月, 2006 1 次提交
  2. 30 12月, 2005 1 次提交
  3. 09 12月, 2005 1 次提交
    • D
      [PATCH] powerpc: Add missing icache flushes for hugepages · cbf52afd
      David Gibson 提交于
      On most powerpc CPUs, the dcache and icache are not coherent so
      between writing and executing a page, the caches must be flushed.
      Userspace programs assume pages given to them by the kernel are icache
      clean, so we must do this flush between the kernel clearing a page and
      it being mapped into userspace for execute.  We were not doing this
      for hugepages, this patch corrects the situation.
      
      We use the same lazy mechanism as we use for normal pages, delaying
      the flush until userspace actually attempts to execute from the page
      in question.
      
      Tested on G5.
      Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      cbf52afd
  4. 10 11月, 2005 1 次提交
  5. 08 11月, 2005 2 次提交
  6. 07 11月, 2005 3 次提交
    • D
      [PATCH] ppc64: Fix bug in SLB miss handler for hugepages · 7d24f0b8
      David Gibson 提交于
      This patch, however, should be applied on top of the 64k-page-size patch to
      fix some problems with hugepage (some pre-existing, another introduced by
      this patch).
      
      The patch fixes a bug in the SLB miss handler for hugepages on ppc64
      introduced by the dynamic hugepage patch (commit id
      c594adad) due to a misunderstanding of the
      srd instruction's behaviour (mea culpa).  The problem arises when a 64-bit
      process maps some hugepages in the low 4GB of the address space (unusual).
      In this case, as well as the 256M segment in question being marked for
      hugepages, other segments at 32G intervals will be incorrectly marked for
      hugepages.
      
      In the process, this patch tweaks the semantics of the hugepage bitmaps to
      be more sensible.  Previously, an address below 4G was marked for hugepages
      if the appropriate segment bit in the "low areas" bitmask was set *or* if
      the low bit in the "high areas" bitmap was set (which would mark all
      addresses below 1TB for hugepage).  With this patch, any given address is
      governed by a single bitmap.  Addresses below 4GB are marked for hugepage
      if and only if their bit is set in the "low areas" bitmap (256M
      granularity).  Addresses between 4GB and 1TB are marked for hugepage iff
      the low bit in the "high areas" bitmap is set.  Higher addresses are marked
      for hugepage iff their bit in the "high areas" bitmap is set (1TB
      granularity).
      
      To avoid conflicts, this patch must be applied on top of BenH's pending
      patch for 64k base page size [0].  As such, this patch also addresses a
      hugepage problem introduced by that patch.  That patch allows hugepages of
      1MB in size on hardware which supports it, however, that won't work when
      using 4k pages (4 level pagetable), because in that case hugepage PTEs are
      stored at the PMD level, and each PMD entry maps 2MB.  This patch simply
      disallows hugepages in that case (we can do something cleverer to re-enable
      them some other day).
      
      Built, booted, and a handful of hugepage related tests passed on POWER5
      LPAR (both ARCH=powerpc and ARCH=ppc64).
      
      [0] http://gate.crashing.org/~benh/ppc64-64k-pages.diffSigned-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      7d24f0b8
    • D
      [PATCH] powerpc: Kill ppcdebug · dcad47fc
      David Gibson 提交于
      The ancient ppcdebug/PPCDBG mechanism is now only used in two places.
      First, in the hash setup code, one of the bits allows the size of the
      hash table to be reduced by a factor of 8 - which would be better
      accomplished with a command line option for that purpose.  The other
      was a bunch of bus walking related messages in the iSeries code, which
      would seem to be insufficient reason to keep the mechanism.
      
      This patch removes the last traces of this mechanism.
      
      Built and booted on iSeries and pSeries POWER5 LPAR (ARCH=powerpc).
      Signed-off-by: NDavid Gibson <dwg@au1.ibm.com>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      dcad47fc
    • B
      [PATCH] ppc64: support 64k pages · 3c726f8d
      Benjamin Herrenschmidt 提交于
      Adds a new CONFIG_PPC_64K_PAGES which, when enabled, changes the kernel
      base page size to 64K.  The resulting kernel still boots on any
      hardware.  On current machines with 4K pages support only, the kernel
      will maintain 16 "subpages" for each 64K page transparently.
      
      Note that while real 64K capable HW has been tested, the current patch
      will not enable it yet as such hardware is not released yet, and I'm
      still verifying with the firmware architects the proper to get the
      information from the newer hypervisors.
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      3c726f8d
  7. 12 10月, 2005 1 次提交
  8. 10 10月, 2005 1 次提交
  9. 23 9月, 2005 1 次提交
    • M
      ppc64 iSeries: Update create_pte_mapping to replace iSeries_bolt_kernel() · 4c55130b
      Michael Ellerman 提交于
      early_setup() calls htab_initialize() which is similar, but not identical
      to iSeries_bolt_kernel().
      
      On iSeries the Hypervisor has already inserted some ptes for us, and we
      simply have to detect that and bolt them. iSeries_hpte_bolt_or_insert()
      implements that logic.
      
      For the case of a non-existing pte we just call iSeries_hpte_insert(). This
      appears to work, although it's not entirely equivalent to the old code in
      iSeries_make_pte() which panicked if we got a secondary slot. Not sure if
      that's important.
      
      Finally we call iSeries_hpte_bolt_or_insert() from create_pte_mapping(),
      which is called from htab_initialize() for each lmb region.
      Signed-off-by: NMichael Ellerman <michael@ellerman.id.au>
      Signed-off-by: NStephen Rothwell <sfr@canb.auug.org.au>
      4c55130b
  10. 21 9月, 2005 1 次提交
  11. 29 8月, 2005 2 次提交
  12. 14 7月, 2005 1 次提交
  13. 22 6月, 2005 2 次提交
  14. 06 5月, 2005 1 次提交
    • D
      [PATCH] ppc64: pgtable.h and other header cleanups · 1f8d419e
      David Gibson 提交于
      This patch started as simply removing a few never-used macros from
      asm-ppc64/pgtable.h, then kind of grew.  It now makes a bunch of
      cleanups to the ppc64 low-level header files (with corresponding
      changes to .c files where necessary) such as:
      	- Abolishing never-used macros
      	- Eliminating multiple #defines with the same purpose
      	- Removing pointless macros (cases where just expanding the
      macro everywhere turns out clearer and more sensible)
      	- Removing some cases where macros which could be defined in
      terms of each other weren't
      	- Moving imalloc() related definitions from pgtable.h to their
      own header file (imalloc.h)
      	- Re-arranging headers to group things more logically
      	- Moving all VSID allocation related things to mmu.h, instead
      of being split between mmu.h and mmu_context.h
      	- Removing some reserved space for flags from the PMD - we're
      not using it.
      	- Fix some bugs which broke compile with STRICT_MM_TYPECHECKS.
      Signed-off-by: NDavid Gibson <dwg@au1.ibm.com>
      Acked-by: NPaul Mackerras <paulus@samba.org>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      1f8d419e
  15. 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