1. 05 4月, 2008 2 次提交
  2. 07 3月, 2008 2 次提交
  3. 08 2月, 2008 1 次提交
    • B
      Introduce flags for reserve_bootmem() · 72a7fe39
      Bernhard Walle 提交于
      This patchset adds a flags variable to reserve_bootmem() and uses the
      BOOTMEM_EXCLUSIVE flag in crashkernel reservation code to detect collisions
      between crashkernel area and already used memory.
      
      This patch:
      
      Change the reserve_bootmem() function to accept a new flag BOOTMEM_EXCLUSIVE.
      If that flag is set, the function returns with -EBUSY if the memory already
      has been reserved in the past.  This is to avoid conflicts.
      
      Because that code runs before SMP initialisation, there's no race condition
      inside reserve_bootmem_core().
      
      [akpm@linux-foundation.org: coding-style fixes]
      [akpm@linux-foundation.org: fix powerpc build]
      Signed-off-by: NBernhard Walle <bwalle@suse.de>
      Cc: <linux-arch@vger.kernel.org>
      Cc: "Eric W. Biederman" <ebiederm@xmission.com>
      Cc: Vivek Goyal <vgoyal@in.ibm.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      72a7fe39
  4. 06 2月, 2008 1 次提交
  5. 19 12月, 2007 1 次提交
    • D
      [IA64] Avoid unnecessary TLB flushes when allocating memory · aec103bf
      de Dinechin, Christophe (Integrity VM) 提交于
      Improve performance of memory allocations on ia64 by avoiding a global TLB
      purge to purge a single page from the file cache. This happens whenever we
      evict a page from the buffer cache to make room for some other allocation.
      
      Test case: Run 'find /usr -type f | xargs cat > /dev/null' in the
      background to fill the buffer cache, then run something that uses memory,
      e.g. 'gmake -j50 install'. Instrumentation showed that the number of
      global TLB purges went from a few millions down to about 170 over a 12
      hours run of the above.
      
      The performance impact is particularly noticeable under virtualization,
      because a virtual TLB is generally both larger and slower to purge than
      a physical one.
      Signed-off-by: NChristophe de Dinechin <ddd@hp.com>
      Signed-off-by: NTony Luck <tony.luck@intel.com>
      aec103bf
  6. 08 12月, 2007 1 次提交
  7. 07 11月, 2007 1 次提交
    • T
      [IA64] Fix section mismatch in contig.c version of per_cpu_init() · 4b9ddc7c
      Tony Luck 提交于
      There is a section mismatch when building CONFIG_FLATMEM=y kernels
      that also have CONFIG_HOTPLUG_CPU=y
      
      WARNING: vmlinux.o(.text+0x5a902): Section mismatch: reference to \
      .init.text:__alloc_bootmem (between 'per_cpu_init' and 'count_pages')
      
      The issue occurs because per_cpu_init() in mm/contig.c is
      marked __cpuinit (which is #define'd to nothing on a hot
      plug cpu configuration) call __alloc_bootmem() (which is
      an __init function).  The usage is actually safe because
      the __alloc_bootmem() is inside an "if (first_time)" test
      so that the call is only made while it is still legal to
      do so.
      
      But the warning is irritating.  Move the allocation to
      find_memory().
      Signed-off-by: NTony Luck <tony.luck@intel.com>
      4b9ddc7c
  8. 30 10月, 2007 1 次提交
    • A
      [IA64] ia64/mm/init.c: fix section mismatches · 18b8befd
      Adrian Bunk 提交于
      This patch fixes the following section mismatches:
      
      <--  snip  -->
      
      ...
      WARNING: vmlinux.o(.text+0x5b5c2): Section mismatch: reference to .init.text:memmap_init_zone (between 'memmap_init' and 'virtual_memmap_init')
      WARNING: vmlinux.o(.text+0x5b842): Section mismatch: reference to .init.text:memmap_init_zone (between 'virtual_memmap_init' and 'ia64_mmu_init')
      ...
      
      <--  snip  -->
      Signed-off-by: NAdrian Bunk <bunk@kernel.org>
      Signed-off-by: NTony Luck <tony.luck@intel.com>
      18b8befd
  9. 20 10月, 2007 2 次提交
    • S
      pid namespaces: define is_global_init() and is_container_init() · b460cbc5
      Serge E. Hallyn 提交于
      is_init() is an ambiguous name for the pid==1 check.  Split it into
      is_global_init() and is_container_init().
      
      A cgroup init has it's tsk->pid == 1.
      
      A global init also has it's tsk->pid == 1 and it's active pid namespace
      is the init_pid_ns.  But rather than check the active pid namespace,
      compare the task structure with 'init_pid_ns.child_reaper', which is
      initialized during boot to the /sbin/init process and never changes.
      
      Changelog:
      
      	2.6.22-rc4-mm2-pidns1:
      	- Use 'init_pid_ns.child_reaper' to determine if a given task is the
      	  global init (/sbin/init) process. This would improve performance
      	  and remove dependence on the task_pid().
      
      	2.6.21-mm2-pidns2:
      
      	- [Sukadev Bhattiprolu] Changed is_container_init() calls in {powerpc,
      	  ppc,avr32}/traps.c for the _exception() call to is_global_init().
      	  This way, we kill only the cgroup if the cgroup's init has a
      	  bug rather than force a kernel panic.
      
      [akpm@linux-foundation.org: fix comment]
      [sukadev@us.ibm.com: Use is_global_init() in arch/m32r/mm/fault.c]
      [bunk@stusta.de: kernel/pid.c: remove unused exports]
      [sukadev@us.ibm.com: Fix capability.c to work with threaded init]
      Signed-off-by: NSerge E. Hallyn <serue@us.ibm.com>
      Signed-off-by: NSukadev Bhattiprolu <sukadev@us.ibm.com>
      Acked-by: NPavel Emelianov <xemul@openvz.org>
      Cc: Eric W. Biederman <ebiederm@xmission.com>
      Cc: Cedric Le Goater <clg@fr.ibm.com>
      Cc: Dave Hansen <haveblue@us.ibm.com>
      Cc: Herbert Poetzel <herbert@13thfloor.at>
      Cc: Kirill Korotaev <dev@sw.ru>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      b460cbc5
    • C
      setup vma->vm_page_prot by vm_get_page_prot() · 3ed75eb8
      Coly Li 提交于
      This patch uses vm_get_page_prot() to setup vma->vm_page_prot.
      
      Though inside vm_get_page_prot() the protection flags is AND with
      (VM_READ|VM_WRITE|VM_EXEC|VM_SHARED), it does not hurt correct code.
      Signed-off-by: NColy Li <coyli@suse.de>
      Cc: Hugh Dickins <hugh@veritas.com>
      Cc: Tony Luck <tony.luck@intel.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      3ed75eb8
  10. 17 10月, 2007 7 次提交
  11. 01 9月, 2007 1 次提交
  12. 31 8月, 2007 1 次提交
    • D
      hugepage: fix broken check for offset alignment in hugepage mappings · dec4ad86
      David Gibson 提交于
      For hugepage mappings, the file offset, like the address and size, needs to
      be aligned to the size of a hugepage.
      
      In commit 68589bc3, the check for this was
      moved into prepare_hugepage_range() along with the address and size checks.
       But since BenH's rework of the get_unmapped_area() paths leading up to
      commit 4b1d8929, prepare_hugepage_range()
      is only called for MAP_FIXED mappings, not for other mappings.  This means
      we're no longer ever checking for an aligned offset - I've confirmed that
      mmap() will (apparently) succeed with a misaligned offset on both powerpc
      and i386 at least.
      
      This patch restores the check, removing it from prepare_hugepage_range()
      and putting it back into hugetlbfs_file_mmap().  I'm putting it there,
      rather than in the get_unmapped_area() path so it only needs to go in one
      place, than separately in the half-dozen or so arch-specific
      implementations of hugetlb_get_unmapped_area().
      Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
      Cc: Adam Litke <agl@us.ibm.com>
      Cc: Andi Kleen <ak@suse.de>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      dec4ad86
  13. 17 8月, 2007 1 次提交
    • A
      [IA64] Failure to grow RBS · e8c59c0c
      Andrew Burgess 提交于
      There is a bug in the ia64_do_page_fault code that can cause a failure
      to grow the register backing store, or any mapping that is marked as
      VM_GROWSUP if the mapping is the highest mapped area of memory.
      
      When the address accessed is below the first mapping the previous mapping
      is returned as NULL, and this case is handled.  However, when the address
      accessed is above the highest mapping the vma returned is NULL, this
      case is not handled correctly, and it fails to spot that this access
      might require an existing mapping to grow upwards.
      Signed-off-by: NAndrew Burgess <andrew@transitive.com>
      Signed-off-by: NTony Luck <tony.luck@intel.com>
      e8c59c0c
  14. 20 7月, 2007 1 次提交
    • N
      mm: fault feedback #2 · 83c54070
      Nick Piggin 提交于
      This patch completes Linus's wish that the fault return codes be made into
      bit flags, which I agree makes everything nicer.  This requires requires
      all handle_mm_fault callers to be modified (possibly the modifications
      should go further and do things like fault accounting in handle_mm_fault --
      however that would be for another patch).
      
      [akpm@linux-foundation.org: fix alpha build]
      [akpm@linux-foundation.org: fix s390 build]
      [akpm@linux-foundation.org: fix sparc build]
      [akpm@linux-foundation.org: fix sparc64 build]
      [akpm@linux-foundation.org: fix ia64 build]
      Signed-off-by: NNick Piggin <npiggin@suse.de>
      Cc: Richard Henderson <rth@twiddle.net>
      Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
      Cc: Russell King <rmk@arm.linux.org.uk>
      Cc: Ian Molton <spyro@f2s.com>
      Cc: Bryan Wu <bryan.wu@analog.com>
      Cc: Mikael Starvik <starvik@axis.com>
      Cc: David Howells <dhowells@redhat.com>
      Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
      Cc: "Luck, Tony" <tony.luck@intel.com>
      Cc: Hirokazu Takata <takata@linux-m32r.org>
      Cc: Geert Uytterhoeven <geert@linux-m68k.org>
      Cc: Roman Zippel <zippel@linux-m68k.org>
      Cc: Greg Ungerer <gerg@uclinux.org>
      Cc: Matthew Wilcox <willy@debian.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Paul Mundt <lethal@linux-sh.org>
      Cc: Kazumoto Kojima <kkojima@rr.iij4u.or.jp>
      Cc: Richard Curnow <rc@rc0.org.uk>
      Cc: William Lee Irwin III <wli@holomorphy.com>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Jeff Dike <jdike@addtoit.com>
      Cc: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
      Cc: Miles Bader <uclinux-v850@lsi.nec.co.jp>
      Cc: Chris Zankel <chris@zankel.net>
      Acked-by: NKyle McMartin <kyle@mcmartin.ca>
      Acked-by: NHaavard Skinnemoen <hskinnemoen@atmel.com>
      Acked-by: NRalf Baechle <ralf@linux-mips.org>
      Acked-by: NAndi Kleen <ak@muc.de>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      [ Still apparently needs some ARM and PPC loving - Linus ]
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      83c54070
  15. 12 7月, 2007 1 次提交
  16. 27 6月, 2007 1 次提交
  17. 17 5月, 2007 1 次提交
  18. 12 5月, 2007 2 次提交
  19. 09 5月, 2007 4 次提交
  20. 08 5月, 2007 2 次提交
  21. 31 3月, 2007 2 次提交
    • B
      [IA64] make ioremap avoid unsupported attributes · 9b50ffb0
      Bjorn Helgaas 提交于
      Example memory map (from HP sx1000 with VGA enabled):
          0x00000 - 0x9FFFF supports only WB (cacheable) access
          0xA0000 - 0xBFFFF supports only UC (uncacheable) access
          0xC0000 - 0xFFFFF supports only WB (cacheable) access
      
      pci_read_rom() indirectly uses ioremap(0xC0000) to read the shadow VGA option
      ROM.  ioremap() used to default to a 16MB or 64MB UC kernel identity mapping,
      which would cause an MCA when reading 0xC0000 since only WB is supported there.
      
      X uses reads the option ROM to initialize devices.  A smaller test case is:
        # echo 1 > /sys/bus/pci/devices/0000:aa:03.0/rom
        # cp /sys/bus/pci/devices/0000:aa:03.0/rom x
      
      To avoid this, we can use the same ioremap_page_range() strategy that most
      architectures use for all ioremaps.  These page table mappings come out of the
      vmalloc area.  On ia64, these are in region 5 (0xA... addresses) and typically
      use 16KB or 64KB mappings instead of 16MB or 64MB mappings.  The smaller
      mappings give more flexibility to use the correct attributes.
      Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com>
      Signed-off-by: NTony Luck <tony.luck@intel.com>
      9b50ffb0
    • B
      [IA64] rename ioremap variables to match i386 · c4add2e5
      Bjorn Helgaas 提交于
      No functional change, just use the same names as i386.
      Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com>
      Signed-off-by: NTony Luck <tony.luck@intel.com>
      c4add2e5
  22. 30 3月, 2007 1 次提交
    • K
      [IA64] bugfix stack layout upside-down · 83d2cd3d
      KAMEZAWA Hiroyuki 提交于
      ia64 expects following vm layout:
      
      == low memory
      [register-stack grows up]
      [memory-stack grows down]
      == high memory
      
      But the code assigns the base of the register stack at the
      maximum stack size offset from the fixed address where the
      stack *might* start.  Stack randomization will result in the
      memory stack starting at a lower address than this, and if the
      user has set a low stack limit with "ulimit -s", then you can
      end up with the register stack above the memory stack (or if
      you were very unlucky right on top of it!).
      
      Fix: Calculate the base address for the register stack starting
      from the actual address of the memory stack.
      Signed-off-by: NKAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
      Signed-off-by: NTony Luck <tony.luck@intel.com>
      83d2cd3d
  23. 21 3月, 2007 1 次提交
    • Z
      [IA64] min_low_pfn and max_low_pfn calculation fix · a3f5c338
      Zou Nan hai 提交于
      We have seen bad_pte_print when testing crashdump on an SN machine in
      recent 2.6.20 kernel.  There are tons of bad pte print (pfn < max_low_pfn)
      reports when the crash kernel boots up, all those reported bad pages
      are inside initmem range; That is because if the crash kernel code and
      data happens to be at the beginning of the 1st node. build_node_maps in
      discontig.c will bypass reserved regions with filter_rsvd_memory. Since
      min_low_pfn is calculated in build_node_map, so in this case, min_low_pfn
      will be greater than kernel code and data.
      
      Because pages inside initmem are freed and reused later, we saw
      pfn_valid check fail on those pages.
      
      I think this theoretically happen on a normal kernel. When I check
      min_low_pfn and max_low_pfn calculation in contig.c and discontig.c.
      I found more issues than this.
      
      1. min_low_pfn and max_low_pfn calculation is inconsistent between
      contig.c and discontig.c,
      min_low_pfn is calculated as the first page number of boot memmap in
      contig.c (Why? Though this may work at the most of the time, I don't
      think it is the right logic). It is calculated as the lowest physical
      memory page number bypass reserved regions in discontig.c.
      max_low_pfn is calculated include reserved regions in contig.c. It is
      calculated exclude reserved regions in discontig.c.
      
      2. If kernel code and data region is happen to be at the begin or the
      end of physical memory, when min_low_pfn and max_low_pfn calculation is
      bypassed kernel code and data, pages in initmem will report bad.
      
      3. initrd is also in reserved regions, if it is at the begin or at the
      end of physical memory, kernel will refuse to reuse the memory. Because
      the virt_addr_valid check in free_initrd_mem.
      
      So it is better to fix and clean up those issues.
      Calculate min_low_pfn and max_low_pfn in a consistent way.
      Signed-off-by: NZou Nan hai <nanhai.zou@intel.com>
      Acked-by: NJay Lan <jlan@sgi.com>
      Signed-off-by: NTony Luck <tony.luck@intel.com>
      a3f5c338
  24. 07 3月, 2007 1 次提交
  25. 12 2月, 2007 1 次提交