1. 17 2月, 2016 1 次提交
    • K
      ARM: 8411/1: Add default SPARSEMEM settings · db57f88e
      Kevin Cernekee 提交于
      We can still override these settings via mach/memory.h, but let's provide
      sensible defaults so that SPARSEMEM is available in the multiplatform
      kernels.
      
      Two platforms currently use SECTION_SIZE_BITS < 28, but are expected to
      work with 28 (albeit slightly less efficiently if not all banks are
      populated):
      
       - mach-rpc: uses 26 bits.  Based on mach/hardware.h it looks like this
         platform puts RAM at 0x1000_0000 - 0x1fff_ffff, and I/O below
         0x1000_0000.
      
       - mach-sa1100: uses 27 bits.  mach/memory.h indicates that RAM occupies
         the entire range of 0xc000_0000 - 0xdfff_ffff.
      
      But Arnd says in that rpc and sa1100 will never have to use the
      default since they cannot be part of a multiplatform kernel, and that
      is unlikely to change.
      
      Several platforms need MAX_PHYSMEM_BITS >= 36 so we'll pick that as the
      minimum.  Anything higher and we'll fail the SECTIONS_WIDTH + NODES_WIDTH +
      ZONES_WIDTH test in <linux/mm.h>.
      
      Some analysis from Russell King at
      http://lists.infradead.org/pipermail/linux-arm-kernel/2014-October/298957.html:
      
        I think this is fine in as far as it goes - this means we end up with
        256 entries in the mem_section array which means it occupies one page,
        which I think is acceptable overhead.
      
        The other thing to be aware of here is the obvious:
      
        #if (MAX_ORDER - 1 + PAGE_SHIFT) > SECTION_SIZE_BITS
        #error Allocator MAX_ORDER exceeds SECTION_SIZE
        #endif
      
        Which means that with 28 bits of section, that's a maximum allocator
        order of 16.  We appear to allow FORCE_MAX_ZONEORDER to be set up to
        64 in the case of shmobile, which doesn't seem like a sensible upper
        limit - and certainly isn't when sparsemem is enabled.
      
        Given this, I think that FORCE_MAX_ZONEORDER's help, and the
        dependencies probably could do with some improvement to make the
        issues more transparent.
      
      [gregory.0xf0: added notes from Arnd and Russell]
      Signed-off-by: NKevin Cernekee <cernekee@gmail.com>
      Acked-by: NArnd Bergmann <arnd@arndb.de>
      Tested-by: NStephen Boyd <sboyd@codeaurora.org>
      Signed-off-by: NGregory Fong <gregory.0xf0@gmail.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      db57f88e
  2. 02 10月, 2008 1 次提交
  3. 03 8月, 2008 1 次提交
  4. 19 4月, 2008 1 次提交