1. 18 12月, 2010 2 次提交
    • C
      x86: this_cpu_cmpxchg and this_cpu_xchg operations · 7296e08a
      Christoph Lameter 提交于
      Provide support as far as the hardware capabilities of the x86 cpus
      allow.
      
      Define CONFIG_CMPXCHG_LOCAL in Kconfig.cpu to allow core code to test for
      fast cpuops implementations.
      
      V1->V2:
      	- Take out the definition for this_cpu_cmpxchg_8 and move it into
      	  a separate patch.
      
      tj: - Reordered ops to better follow this_cpu_* organization.
          - Renamed macro temp variables similar to their existing
            neighbours.
      Signed-off-by: NChristoph Lameter <cl@linux.com>
      Signed-off-by: NTejun Heo <tj@kernel.org>
      7296e08a
    • C
      percpu: Generic this_cpu_cmpxchg() and this_cpu_xchg support · 2b712442
      Christoph Lameter 提交于
      Generic code to provide new per cpu atomic features
      
      	this_cpu_cmpxchg
      	this_cpu_xchg
      
      Fallback occurs to functions using interrupts disable/enable
      to ensure correct per cpu atomicity.
      
      Fallback to regular cmpxchg and xchg is not possible since per cpu atomic
      semantics include the guarantee that the current cpus per cpu data is
      accessed atomically. Use of regular cmpxchg and xchg requires the
      determination of the address of the per cpu data before regular cmpxchg
      or xchg which therefore cannot be atomically included in an xchg or
      cmpxchg without segment override.
      
      tj: - Relocated new ops to conform better to the general organization.
          - This patch contains a trivial comment fix.
      Signed-off-by: NChristoph Lameter <cl@linux.com>
      Signed-off-by: NTejun Heo <tj@kernel.org>
      2b712442
  2. 17 12月, 2010 36 次提交
  3. 16 12月, 2010 2 次提交
    • R
      lguest: populate initial_page_table · da32dac1
      Rusty Russell 提交于
      Two x86 patches broke lguest:
      1) v2.6.35-492-g72d7c3b3, which changed x86 to use the memblock allocator.
      
      In lguest, the host places linear page tables at the top of mem, which
      used to be enough to get us up to the swapper_pg_dir page tables.  With
      the first patch, the direct mapping tables used that memory:
      
      Before: kernel direct mapping tables up to 4000000 @ 7000-1a000
      After: kernel direct mapping tables up to 4000000 @ 3fed000-4000000
      
      I initially fixed this by lying about the amount of memory we had, so
      the kernel wouldn't blatt the lguest boot pagetables (yuk!), but then...
      
      2) v2.6.36-rc8-54-gb40827fa, which made x86 boot use initial_page_table.
      
      This was initialized in a part of head_32.S which isn't executed by
      lguest; it is then copied into swapper_pg_dir.  So we have to initialize
      it; and anyway we switch to it before we blatt the old tables, so that
      fixes the previous damage as well.
      
      For the moment, I cut & pasted the code into lguest's boot code, but
      next merge window I will merge them.
      Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
      Cc: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
      Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      To: x86@kernel.org
      da32dac1
    • R
      lguest: restore boot speed · bb4093de
      Rusty Russell 提交于
      lguest is dumb and drops *all* the pagetables for set_pte (which is
      only used for kernel mapping manipulation, so it's OK without highmem).
      
      But it's used a lot in boot, too.  As a guest optimization, we
      suppressed this flushing until the first page switch.  Now we have
      initial_page_table, that happens much earlier, so extend the heuristic
      to wait until we switch to something other than the swapper_pg_dir or
      initial_page_table.
      
      As measured on my laptop under kvm, this dropped the time-to-mount-root
      from 48 seconds to 4.3 seconds.
      Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
      bb4093de