1. 22 6月, 2005 3 次提交
    • J
      [PATCH] ia64 uncached alloc · f14f75b8
      Jes Sorensen 提交于
      This patch contains the ia64 uncached page allocator and the generic
      allocator (genalloc).  The uncached allocator was formerly part of the SN2
      mspec driver but there are several other users of it so it has been split
      off from the driver.
      
      The generic allocator can be used by device driver to manage special memory
      etc.  The generic allocator is based on the allocator from the sym53c8xx_2
      driver.
      
      Various users on ia64 needs uncached memory.  The SGI SN architecture requires
      it for inter-partition communication between partitions within a large NUMA
      cluster.  The specific user for this is the XPC code.  Another application is
      large MPI style applications which use it for synchronization, on SN this can
      be done using special 'fetchop' operations but it also benefits non SN
      hardware which may use regular uncached memory for this purpose.  Performance
      of doing this through uncached vs cached memory is pretty substantial.  This
      is handled by the mspec driver which I will push out in a seperate patch.
      
      Rather than creating a specific allocator for just uncached memory I came up
      with genalloc which is a generic purpose allocator that can be used by device
      drivers and other subsystems as they please.  For instance to handle onboard
      device memory.  It was derived from the sym53c7xx_2 driver's allocator which
      is also an example of a potential user (I am refraining from modifying sym2
      right now as it seems to have been under fairly heavy development recently).
      
      On ia64 memory has various properties within a granule, ie.  it isn't safe to
      access memory as uncached within the same granule as currently has memory
      accessed in cached mode.  The regular system therefore doesn't utilize memory
      in the lower granules which is mixed in with device PAL code etc.  The
      uncached driver walks the EFI memmap and pulls out the spill uncached pages
      and sticks them into the uncached pool.  Only after these chunks have been
      utilized, will it start converting regular cached memory into uncached memory.
      Hence the reason for the EFI related code additions.
      Signed-off-by: NJes Sorensen <jes@wildopensource.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      f14f75b8
    • D
      [PATCH] Hugepage consolidation · 63551ae0
      David Gibson 提交于
      A lot of the code in arch/*/mm/hugetlbpage.c is quite similar.  This patch
      attempts to consolidate a lot of the code across the arch's, putting the
      combined version in mm/hugetlb.c.  There are a couple of uglyish hacks in
      order to covert all the hugepage archs, but the result is a very large
      reduction in the total amount of code.  It also means things like hugepage
      lazy allocation could be implemented in one place, instead of six.
      
      Tested, at least a little, on ppc64, i386 and x86_64.
      
      Notes:
      	- this patch changes the meaning of set_huge_pte() to be more
      	  analagous to set_pte()
      	- does SH4 need s special huge_ptep_get_and_clear()??
      Acked-by: NWilliam Lee Irwin <wli@holomorphy.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      63551ae0
    • M
      [PATCH] VM: early zone reclaim · 753ee728
      Martin Hicks 提交于
      This is the core of the (much simplified) early reclaim.  The goal of this
      patch is to reclaim some easily-freed pages from a zone before falling back
      onto another zone.
      
      One of the major uses of this is NUMA machines.  With the default allocator
      behavior the allocator would look for memory in another zone, which might be
      off-node, before trying to reclaim from the current zone.
      
      This adds a zone tuneable to enable early zone reclaim.  It is selected on a
      per-zone basis and is turned on/off via syscall.
      
      Adding some extra throttling on the reclaim was also required (patch
      4/4).  Without the machine would grind to a crawl when doing a "make -j"
      kernel build.  Even with this patch the System Time is higher on
      average, but it seems tolerable.  Here are some numbers for kernbench
      runs on a 2-node, 4cpu, 8Gig RAM Altix in the "make -j" run:
      
      			wall  user   sys   %cpu  ctx sw.  sleeps
      			----  ----   ---   ----   ------  ------
      No patch		1009  1384   847   258   298170   504402
      w/patch, no reclaim     880   1376   667   288   254064   396745
      w/patch & reclaim       1079  1385   926   252   291625   548873
      
      These numbers are the average of 2 runs of 3 "make -j" runs done right
      after system boot.  Run-to-run variability for "make -j" is huge, so
      these numbers aren't terribly useful except to seee that with reclaim
      the benchmark still finishes in a reasonable amount of time.
      
      I also looked at the NUMA hit/miss stats for the "make -j" runs and the
      reclaim doesn't make any difference when the machine is thrashing away.
      
      Doing a "make -j8" on a single node that is filled with page cache pages
      takes 700 seconds with reclaim turned on and 735 seconds without reclaim
      (due to remote memory accesses).
      
      The simple zone_reclaim syscall program is at
      http://www.bork.org/~mort/sgi/zone_reclaim.cSigned-off-by: NMartin Hicks <mort@sgi.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      753ee728
  2. 21 6月, 2005 2 次提交
  3. 10 6月, 2005 1 次提交
    • C
      [IA64] Fix race condition in the rt_sigprocmask fastcall · a2a64769
      Christoph Lameter 提交于
      current->blocked will be set to the value of current->thread_info->flags if the
      cmpxchg to update thread_info->flags fails. For performance reasons the store into
      current->blocked was placed in the cmpxchg loop. However, the cmpxchg overwrites the
      register holding the value to be stored. In the rare case of a retry the value of
      thread_info->flags will be written into current->blocked.
      
      The fix is to use another register so that the register containing the current->blocked
      value is not overwritten.
      Signed-off-by: NChristoph Lameter <clameter@sgi.com>
      Signed-off-by: NTony Luck <tony.luck@intel.com>
      a2a64769
  4. 09 6月, 2005 5 次提交
  5. 04 6月, 2005 1 次提交
  6. 02 6月, 2005 2 次提交
  7. 01 6月, 2005 1 次提交
  8. 27 5月, 2005 1 次提交
  9. 19 5月, 2005 2 次提交
    • T
      [IA64] initialize spinlock pfm_alt_install_check · fe12e25e
      Tony Luck 提交于
      I applied the penultimate version of the perfmon patch, which didn't have
      the initialization of the new spinlock that was added.
      Signed-off-by: NTony Luck <tony.luck@intel.com>
      fe12e25e
    • T
      [IA64] alternate perfmon handler · a1ecf7f6
      Tony Luck 提交于
      Patch from Charles Spirakis
      
      Some linux customers want to optimize their applications on the latest
      hardware but are not yet willing to upgrade to the latest kernel. This
      patch provides a way to plug in an alternate, basic, and GPL'ed PMU
      subsystem to help with their monitoring needs or for specialty work. It
      can also be used in case of serious unexpected bugs in perfmon. Mutual
      exclusion between the two subsystems is guaranteed, hence no conflict
      can arise from both subsystem being present.
      Acked-by: NStephane Eranian <eranian@hpl.hp.com>
      Signed-off-by: NTony Luck <tony.luck@intel.com>
      a1ecf7f6
  10. 18 5月, 2005 3 次提交
  11. 17 5月, 2005 1 次提交
  12. 11 5月, 2005 1 次提交
    • D
      [IA64] Avoid .spillpsp directive in handcoded assembly · bfd68594
      David Mosberger-Tang 提交于
      Some time ago, GAS was fixed to bring the .spillpsp directive in line
      with the Intel assembler manual (there was some disagreement as to
      whether or not there is a built-in 16-byte offset).  Unfortunately,
      there are two places in the kernel where this directive is used in
      handwritten assembly files and those of course relied on the "buggy"
      behavior.  As a result, when using a "fixed" assembler, the kernel
      picks up the UNaT bits from the wrong place (off by 16) and randomly
      sets NaT bits on the scratch registers.  This can be noticed easily by
      looking at a coredump and finding various scratch registers with
      unexpected NaT values.  The patch below fixes this by using the
      .spillsp directive instead, which works correctly no matter what
      assembler is in use.
      Signed-off-by: NDavid Mosberger-Tang <davidm@hpl.hp.com>
      Signed-off-by: NTony Luck <tony.luck@intel.com>
      bfd68594
  13. 10 5月, 2005 1 次提交
  14. 07 5月, 2005 1 次提交
  15. 06 5月, 2005 1 次提交
  16. 05 5月, 2005 1 次提交
  17. 04 5月, 2005 13 次提交