1. 30 1月, 2008 3 次提交
    • M
      x86: make NUMA work on 32-bit · 1b000a5d
      Mel Gorman 提交于
      The DISCONTIG memory model on x86 32 bit uses a remap allocator early
      in boot. The objective is that portions of every node are mapped in to
      the kernel virtual area (KVA) in place of ZONE_NORMAL so that node-local
      allocations can be made for pgdat and mem_map structures.
      
      With SPARSEMEM, the amount that is set aside is insufficient for all the
      mem_maps to be allocated. During the boot process, it falls back to using
      the bootmem allocator. This breaks assumptions that SPARSEMEM makes about
      the layout of the mem_map in memory and results in a VM_BUG_ON triggering
      due to pfn_to_page() returning garbage values.
      
      This patch only enables the remap allocator for use with DISCONTIG.
      
      Without SRAT support, a compile-error occurs because ACPI table parsing
      functions are only available in x86-64. This patch also adds no-op stubs
      and prints a warning message. What likely needs to be done is sharing
      the table parsing functions between 32 and 64 bit if they are
      compatible.
      Signed-off-by: NMel Gorman <mel@csn.ul.ie>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      1b000a5d
    • M
      x86: make NUMA work on 32-bit again · bac4894d
      Mel Gorman 提交于
      On 32-bit NUMA, the memmap representing struct pages on each node is
      allocated from node-local memory if possible. As only node-0 has memory from
      ZONE_NORMAL, the memmap must be mapped into low memory. This is done by
      reserving space in the Kernel Virtual Area (KVA) for the memmap belonging
      to other nodes by taking pages from the end of ZONE_NORMAL and remapping
      the other nodes memmap into those virtual addresses. The node boundaries
      are then adjusted so that the region of pages is not used and it is marked
      as reserved in the bootmem allocator.
      
      This reserved portion of the KVA is PMD aligned althought
      strictly speaking that requirement could be lifted (see thread at
      http://lkml.org/lkml/2007/8/24/220). The problem is that when aligned, there
      may be a portion of ZONE_NORMAL at the end that is not used for memmap and
      does not have an initialised memmap nor is it marked reserved in the bootmem
      allocator. Later in the boot process, these pages are freed and a storm of
      Bad page state messages result.
      
      This patch marks these pages reserved that are wasted due to alignment
      in the bootmem allocator so they are not accidently freed. It is worth
      noting that memory from node-0 is wasted where it could have been put into
      ZONE_HIGHMEM on NUMA machines. Worse, the KVA is always reserved from the
      location of real memory even when there is plenty of spare virtual address
      space.
      
      This patch also makes sure that reserve_bootmem() is not called with a
      0-length size in numa_kva_reserve().  When this happens, it usually means
      that a kernel built for Summit is being booted on a normal machine. The
      resulting BUG_ON() is misleading so it is caught here.
      Signed-off-by: NMel Gorman <mel@csn.ul.ie>
      Signed-off-by: NAndy Whitcroft <apw@shadowen.org>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      bac4894d
    • H
      i386: handle an initrd in highmem (version 2) · cf8fa920
      H. Peter Anvin 提交于
      The boot protocol has until now required that the initrd be located in
      lowmem, which makes the lowmem/highmem boundary visible to the boot
      loader.  This was exported to the bootloader via a compile-time
      field.  Unfortunately, the vmalloc= command-line option breaks this
      part of the protocol; instead of adding yet another hack that affects
      the bootloader, have the kernel relocate the initrd down below the
      lowmem boundary inside the kernel itself.
      
      Note that this does not rely on HIGHMEM being enabled in the kernel.
      Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      cf8fa920
  2. 30 10月, 2007 1 次提交
  3. 20 10月, 2007 1 次提交
  4. 18 10月, 2007 1 次提交
  5. 17 10月, 2007 1 次提交
  6. 11 10月, 2007 2 次提交
  7. 16 5月, 2007 1 次提交
  8. 13 2月, 2007 1 次提交
  9. 23 12月, 2006 1 次提交
  10. 07 12月, 2006 1 次提交
  11. 12 10月, 2006 1 次提交
    • M
      [PATCH] mm: use symbolic names instead of indices for zone initialisation · 6391af17
      Mel Gorman 提交于
      Arch-independent zone-sizing is using indices instead of symbolic names to
      offset within an array related to zones (max_zone_pfns).  The unintended
      impact is that ZONE_DMA and ZONE_NORMAL is initialised on powerpc instead
      of ZONE_DMA and ZONE_HIGHMEM when CONFIG_HIGHMEM is set.  As a result, the
      the machine fails to boot but will boot with CONFIG_HIGHMEM turned off.
      
      The following patch properly initialises the max_zone_pfns[] array and uses
      symbolic names instead of indices in each architecture using
      arch-independent zone-sizing.  Two users have successfully booted their
      powerpcs with it (one an ibook G4).  It has also been boot tested on x86,
      x86_64, ppc64 and ia64.  Please merge for 2.6.19-rc2.
      
      Credit to Benjamin Herrenschmidt for identifying the bug and rolling the
      first fix.  Additional credit to Johannes Berg and Andreas Schwab for
      reporting the problem and testing on powerpc.
      Signed-off-by: NMel Gorman <mel@csn.ul.ie>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      6391af17
  12. 04 10月, 2006 1 次提交
  13. 27 9月, 2006 1 次提交
  14. 26 9月, 2006 4 次提交
  15. 01 7月, 2006 2 次提交
  16. 28 3月, 2006 2 次提交
  17. 30 10月, 2005 1 次提交
  18. 08 9月, 2005 1 次提交
  19. 08 8月, 2005 1 次提交
  20. 30 7月, 2005 1 次提交
  21. 26 6月, 2005 1 次提交
  22. 24 6月, 2005 5 次提交
  23. 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