1. 15 Jan, 2006 1 commit
    • Paul Jackson's avatar
      [PATCH] cpuset oom lock fix · 505970b9
      Paul Jackson authored
      The problem, reported in:
      and by various other email messages and lkml posts is that the cpuset hook
      in the oom (out of memory) code can try to take a cpuset semaphore while
      holding the tasklist_lock (a spinlock).
      One must not sleep while holding a spinlock.
      The fix seems easy enough - move the cpuset semaphore region outside the
      tasklist_lock region.
      This required a few lines of mechanism to implement.  The oom code where
      the locking needs to be changed does not have access to the cpuset locks,
      which are internal to kernel/cpuset.c only.  So I provided a couple more
      cpuset interface routines, available to the rest of the kernel, which
      simple take and drop the lock needed here (cpusets callback_sem).
      Signed-off-by: default avatarPaul Jackson <pj@sgi.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
  2. 09 Jan, 2006 1 commit
  3. 08 Oct, 2005 1 commit
  4. 10 Sep, 2005 1 commit
  5. 07 Sep, 2005 2 commits
    • Paul Jackson's avatar
      [PATCH] cpusets: confine oom_killer to mem_exclusive cpuset · ef08e3b4
      Paul Jackson authored
      Now the real motivation for this cpuset mem_exclusive patch series seems
      This patch keeps a task in or under one mem_exclusive cpuset from provoking an
      oom kill of a task under a non-overlapping mem_exclusive cpuset.  Since only
      interrupt and GFP_ATOMIC allocations are allowed to escape mem_exclusive
      containment, there is little to gain from oom killing a task under a
      non-overlapping mem_exclusive cpuset, as almost all kernel and user memory
      allocation must come from disjoint memory nodes.
      This patch enables configuring a system so that a runaway job under one
      mem_exclusive cpuset cannot cause the killing of a job in another such cpuset
      that might be using very high compute and memory resources for a prolonged
      Signed-off-by: default avatarPaul Jackson <pj@sgi.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
    • Paul Jackson's avatar
      [PATCH] cpusets: oom_kill tweaks · a49335cc
      Paul Jackson authored
      This patch series extends the use of the cpuset attribute 'mem_exclusive'
      to support cpuset configurations that:
       1) allow GFP_KERNEL allocations to come from a potentially larger
          set of memory nodes than GFP_USER allocations, and
       2) can constrain the oom killer to tasks running in cpusets in
          a specified subtree of the cpuset hierarchy.
      Here's an example usage scenario.  For a few hours or more, a large NUMA
      system at a University is to be divided in two halves, with a bunch of student
      jobs running in half the system under some form of batch manager, and with a
      big research project running in the other half.  Each of the student jobs is
      placed in a small cpuset, but should share the classic Unix time share
      facilities, such as buffered pages of files in /bin and /usr/lib.  The big
      research project wants no interference whatsoever from the student jobs, and
      has highly tuned, unusual memory and i/o patterns that intend to make full use
      of all the main memory on the nodes available to it.
      In this example, we have two big sibling cpusets, one of which is further
      divided into a more dynamic set of child cpusets.
      We want kernel memory allocations constrained by the two big cpusets, and user
      allocations constrained by the smaller child cpusets where present.  And we
      require that the oom killer not operate across the two halves of this system,
      or else the first time a student job runs amuck, the big research project will
      likely be first inline to get shot.
      Tweaking /proc/<pid>/oom_adj is not ideal -- if the big research project
      really does run amuck allocating memory, it should be shot, not some other
      task outside the research projects mem_exclusive cpuset.
      I propose to extend the use of the 'mem_exclusive' flag of cpusets to manage
      such scenarios.  Let memory allocations for user space (GFP_USER) be
      constrained by a tasks current cpuset, but memory allocations for kernel space
      (GFP_KERNEL) by constrained by the nearest mem_exclusive ancestor of the
      current cpuset, even though kernel space allocations will still _prefer_ to
      remain within the current tasks cpuset, if memory is easily available.
      Let the oom killer be constrained to consider only tasks that are in
      overlapping mem_exclusive cpusets (it won't help much to kill a task that
      normally cannot allocate memory on any of the same nodes as the ones on which
      the current task can allocate.)
      The current constraints imposed on setting mem_exclusive are unchanged.  A
      cpuset may only be mem_exclusive if its parent is also mem_exclusive, and a
      mem_exclusive cpuset may not overlap any of its siblings memory nodes.
      This patch was presented on linux-mm in early July 2005, though did not
      generate much feedback at that time.  It has been built for a variety of
      arch's using cross tools, and built, booted and tested for function on SN2
      There are 4 patches in this set:
        1) Some minor cleanup, and some improvements to the code layout
           of one routine to make subsequent patches cleaner.
        2) Add another GFP flag - __GFP_HARDWALL.  It marks memory
           requests for USER space, which are tightly confined by the
           current tasks cpuset.
        3) Now memory requests (such as KERNEL) that not marked HARDWALL can
           if short on memory, look in the potentially larger pool of memory
           defined by the nearest mem_exclusive ancestor cpuset of the current
           tasks cpuset.
        4) Finally, modify the oom killer to skip any task whose mem_exclusive
           cpuset doesn't overlap ours.
      Patch (1), the one time I looked on an SN2 (ia64) build, actually saved 32
      bytes of kernel text space.  Patch (2) has no affect on the size of kernel
      text space (it just adds a preprocessor flag).  Patches (3) and (4) added
      about 600 bytes each of kernel text space, mostly in kernel/cpuset.c, which
      matters only if CONFIG_CPUSET is enabled.
      This patch:
      This patch applies a few comment and code cleanups to mm/oom_kill.c prior to
      applying a few small patches to improve cpuset management of memory placement.
      The comment changed in oom_kill.c was seriously misleading.  The code layout
      change in select_bad_process() makes room for adding another condition on
      which a process can be spared the oom killer (see the subsequent
      cpuset_nodes_overlap patch for this addition).
      Also a couple typos and spellos that bugged me, while I was here.
      This patch should have no material affect.
      Signed-off-by: default avatarPaul Jackson <pj@sgi.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
  6. 08 Jul, 2005 2 commits
  7. 22 Jun, 2005 1 commit
  8. 16 Apr, 2005 2 commits