1. 13 5月, 2008 1 次提交
  2. 22 4月, 2008 1 次提交
  3. 20 4月, 2008 1 次提交
  4. 18 7月, 2007 1 次提交
    • R
      Freezer: make kernel threads nonfreezable by default · 83144186
      Rafael J. Wysocki 提交于
      Currently, the freezer treats all tasks as freezable, except for the kernel
      threads that explicitly set the PF_NOFREEZE flag for themselves.  This
      approach is problematic, since it requires every kernel thread to either
      set PF_NOFREEZE explicitly, or call try_to_freeze(), even if it doesn't
      care for the freezing of tasks at all.
      
      It seems better to only require the kernel threads that want to or need to
      be frozen to use some freezer-related code and to remove any
      freezer-related code from the other (nonfreezable) kernel threads, which is
      done in this patch.
      
      The patch causes all kernel threads to be nonfreezable by default (ie.  to
      have PF_NOFREEZE set by default) and introduces the set_freezable()
      function that should be called by the freezable kernel threads in order to
      unset PF_NOFREEZE.  It also makes all of the currently freezable kernel
      threads call set_freezable(), so it shouldn't cause any (intentional)
      change of behaviour to appear.  Additionally, it updates documentation to
      describe the freezing of tasks more accurately.
      
      [akpm@linux-foundation.org: build fixes]
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      Acked-by: NNigel Cunningham <nigel@nigel.suspend2.net>
      Cc: Pavel Machek <pavel@ucw.cz>
      Cc: Oleg Nesterov <oleg@tv-sign.ru>
      Cc: Gautham R Shenoy <ego@in.ibm.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      83144186
  5. 08 12月, 2006 1 次提交
  6. 26 6月, 2006 1 次提交
    • A
      [PATCH] pdflush: handle resume wakeups · d616e09a
      Andrew Morton 提交于
      pdflush is carefully designed to ensure that all wakeups have some
      corresponding work to do - if a woken-up pdflush thread discovers that it
      hasn't been given any work to do then this is considered an error.
      
      That all broke when swsusp came along - because a timer-delivered wakeup to a
      frozen pdflush thread will just get lost.  This causes the pdflush thread to
      get lost as well: the writeback timer is supposed to be re-armed by pdflush in
      process context, but pdflush doesn't execute the callout which does this.
      
      Fix that up by ignoring the return value from try_to_freeze(): jsut proceed,
      see if we have any work pending and only go back to sleep if that is not the
      case.
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      d616e09a
  7. 23 6月, 2006 1 次提交
  8. 09 1月, 2006 1 次提交
  9. 31 10月, 2005 1 次提交
    • P
      [PATCH] cpusets: confine pdflush to its cpuset · 28a42b9e
      Paul Jackson 提交于
      This patch keeps pdflush daemons on the same cpuset as their parent, the
      kthread daemon.
      
      Some large NUMA configurations put as much as they can of kernel threads
      and other classic Unix load in what's called a bootcpuset, keeping the rest
      of the system free for dedicated jobs.
      
      This effort is thwarted by pdflush, which dynamically destroys and
      recreates pdflush daemons depending on load.
      
      It's easy enough to force the originally created pdflush deamons into the
      bootcpuset, at system boottime.  But the pdflush threads created later were
      allowed to run freely across the system, due to the necessary line in their
      startup kthread():
      
              set_cpus_allowed(current, CPU_MASK_ALL);
      
      By simply coding pdflush to start its threads with the cpus_allowed
      restrictions of its cpuset (inherited from kthread, its parent) we can
      ensure that dynamically created pdflush threads are also kept in the
      bootcpuset.
      
      On systems w/o cpusets, or w/o a bootcpuset implementation, the following
      will have no affect, leaving pdflush to run on any CPU, as before.
      Signed-off-by: NPaul Jackson <pj@sgi.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      28a42b9e
  10. 26 6月, 2005 1 次提交
    • C
      [PATCH] Cleanup patch for process freezing · 3e1d1d28
      Christoph Lameter 提交于
      1. Establish a simple API for process freezing defined in linux/include/sched.h:
      
         frozen(process)		Check for frozen process
         freezing(process)		Check if a process is being frozen
         freeze(process)		Tell a process to freeze (go to refrigerator)
         thaw_process(process)	Restart process
         frozen_process(process)	Process is frozen now
      
      2. Remove all references to PF_FREEZE and PF_FROZEN from all
         kernel sources except sched.h
      
      3. Fix numerous locations where try_to_freeze is manually done by a driver
      
      4. Remove the argument that is no longer necessary from two function calls.
      
      5. Some whitespace cleanup
      
      6. Clear potential race in refrigerator (provides an open window of PF_FREEZE
         cleared before setting PF_FROZEN, recalc_sigpending does not check
         PF_FROZEN).
      
      This patch does not address the problem of freeze_processes() violating the rule
      that a task may only modify its own flags by setting PF_FREEZE. This is not clean
      in an SMP environment. freeze(process) is therefore not SMP safe!
      Signed-off-by: NChristoph Lameter <christoph@lameter.com>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      3e1d1d28
  11. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      
      Let it rip!
      1da177e4