1. 25 5月, 2008 1 次提交
    • Y
      x86: mtrr cleanup for converting continuous to discrete layout, v8 · 95ffa243
      Yinghai Lu 提交于
      some BIOS like to use continus MTRR layout, and X driver can not add
      WB entries for graphical cards when 4g or more RAM installed.
      
      the patch will change MTRR to discrete.
      
      mtrr_chunk_size= could be used to have smaller continuous block to hold holes.
      default is 256m, could be set according to size of graphics card memory.
      
      mtrr_gran_size= could be used to send smallest mtrr block to avoid run out of MTRRs
      
      v2: fix -1 for UC checking
      v3: default to disable, and need use enable_mtrr_cleanup to enable this feature
          skip the var state change warning.
          remove next_basek in range_to_mtrr()
      v4: correct warning mask.
      v5: CONFIG_MTRR_SANITIZER
      v6: fix 1g, 2g, 512 aligment with extra hole
      v7: gran_sizek to prevent running out of MTRRs.
      v8: fix hole_basek caculation caused when removing next_basek
          gran_sizek using when basek is 0.
      
      need to apply
      	[PATCH] x86: fix trimming e820 with MTRR holes.
      right after this one.
      Signed-off-by: NYinghai Lu <yhlu.kernel@gmail.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      95ffa243
  2. 11 5月, 2008 1 次提交
  3. 08 5月, 2008 1 次提交
  4. 06 5月, 2008 1 次提交
  5. 05 5月, 2008 1 次提交
  6. 01 5月, 2008 2 次提交
    • S
      x86: use defconfigs from x86/configs/* · b9b39bfb
      Sam Ravnborg 提交于
      Daniel Drake <dsd@gentoo.org> reported:
      
      In 2.6.23, if you unpacked a kernel source tarball and then
      ran "make menuconfig" you'd be presented with this message:
          # using defaults found in arch/i386/defconfig
      
      and the default options would be set.
      
      The same thing in 2.6.24 does not give you any "using defaults" message, and
      the default config options within menuconfig are rather blank (e.g. no PCI
      support). You can work around this by explicitly running "make defconfig"
      before menuconfig, but it would be nice to have the behaviour the way it was
      for 2.6.23 (and the way it still is for other archs).
      
      Fixed by adding a x86 specific defconfig list to Kconfig.
      
      Fixes: http://bugzilla.kernel.org/show_bug.cgi?id=10470
      Tested-by: dsd@gentoo.org
      Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      b9b39bfb
    • I
      x86 VISWS: build fix · 3e8f7e35
      Ingo Molnar 提交于
      the 'reboot_force' flag is a notion that non-PC subarchitectures do
      not have.
      
      also, unify the X86_BIOS_REBOOT option between 32-bit and 64-bit
      and get rid of a few unnecessary Kconfig and Makefile complications
      that way.
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      3e8f7e35
  7. 29 4月, 2008 2 次提交
  8. 28 4月, 2008 2 次提交
  9. 27 4月, 2008 7 次提交
  10. 26 4月, 2008 2 次提交
  11. 25 4月, 2008 1 次提交
  12. 20 4月, 2008 2 次提交
  13. 18 4月, 2008 1 次提交
  14. 17 4月, 2008 11 次提交
  15. 13 3月, 2008 1 次提交
  16. 12 3月, 2008 1 次提交
    • T
      x86: remove quicklists · 985a34bd
      Thomas Gleixner 提交于
      quicklists cause a serious memory leak on 32-bit x86,
      as documented at:
      
        http://bugzilla.kernel.org/show_bug.cgi?id=9991
      
      the reason is that the quicklist pool is a special-purpose
      cache that grows out of proportion. It is not accounted for
      anywhere and users have no way to even realize that it's
      the quicklists that are causing RAM usage spikes. It was
      supposed to be a relatively small pool, but as demonstrated
      by KOSAKI Motohiro, they can grow as large as:
      
        Quicklists:    1194304 kB
      
      given how much trouble this code has caused historically,
      and given that Andrew objected to its introduction on x86
      (years ago), the best option at this point is to remove them.
      
      [ any performance benefits of caching constructed pgds should
        be implemented in a more generic way (possibly within the page
        allocator), while still allowing constructed pages to be
        allocated by other workloads. ]
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      985a34bd
  17. 05 3月, 2008 1 次提交
  18. 04 3月, 2008 1 次提交
  19. 23 2月, 2008 1 次提交