1. 30 1月, 2008 2 次提交
  2. 11 10月, 2007 2 次提交
  3. 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
  4. 17 7月, 2007 1 次提交
  5. 10 7月, 2007 1 次提交
  6. 10 5月, 2007 1 次提交
    • R
      Add suspend-related notifications for CPU hotplug · 8bb78442
      Rafael J. Wysocki 提交于
      Since nonboot CPUs are now disabled after tasks and devices have been
      frozen and the CPU hotplug infrastructure is used for this purpose, we need
      special CPU hotplug notifications that will help the CPU-hotplug-aware
      subsystems distinguish normal CPU hotplug events from CPU hotplug events
      related to a system-wide suspend or resume operation in progress.  This
      patch introduces such notifications and causes them to be used during
      suspend and resume transitions.  It also changes all of the
      CPU-hotplug-aware subsystems to take these notifications into consideration
      (for now they are handled in the same way as the corresponding "normal"
      ones).
      
      [oleg@tv-sign.ru: cleanups]
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      Cc: Gautham R Shenoy <ego@in.ibm.com>
      Cc: Pavel Machek <pavel@ucw.cz>
      Signed-off-by: NOleg Nesterov <oleg@tv-sign.ru>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      8bb78442
  7. 17 2月, 2007 2 次提交
  8. 08 12月, 2006 1 次提交
    • Z
      [PATCH] softirq: remove BUG_ONs which can incorrectly trigger · 3908fd2e
      Zachary Amsden 提交于
      It is possible to have tasklets get scheduled before softirqd has had a chance
      to spawn on all CPUs.  This is totally harmless; after success during action
      CPU_UP_PREPARE, action CPU_ONLINE will be called, which immediately wakes
      softirqd on the appropriate CPU to process the already pending tasklets.  So
      there is no danger of having a missed wakeup for any tasklets that were
      already pending.
      
      In particular, i386 is affected by this during startup, and is visible when
      using a very large initrd; during the time it takes for the initrd to be
      decompressed, a timer IRQ can come in and schedule RCU callbacks.  It is also
      possible that resending of a hardware IRQ via a softirq triggers the same bug.
      
      Because of different timing conditions, this shows up in all emulators and
      virtual machines tested, including Xen, VMware, Virtual PC, and Qemu.  It is
      also possible to trigger on native hardware with a large enough initrd,
      although I don't have a reliable case demonstrating that.
      Signed-off-by: NZachary Amsden <zach@vmware.com>
      Cc: <caglar@pardus.org.tr>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: <stable@kernel.org>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      3908fd2e
  9. 30 9月, 2006 1 次提交
  10. 01 8月, 2006 2 次提交
    • T
      [PATCH] Reducing local_bh_enable/disable overhead in irqtrace · 3c829c36
      Tim Chen 提交于
      The recent changes from irqtrace feature has added overheads to
      local_bh_disable and local_bh_enable that reduces UDP performance across
      x86_64 and IA64, even though IA64 does not support the irqtrace feature.
      Patch in question is
      
      [PATCH]lockdep: irqtrace subsystem, core
      http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=c
      ommit;h=de30a2b3
      
      Prior to this patch, local_bh_disable was a short macro.  Now it is a
      function which calls __local_bh_disable with added irq flags save and
      restore.  The irq flags save and restore were also added to
      local_bh_enable, probably for injecting the trace irqs code.
      
      This overhead is on the generic code path across all architectures.  On a
      IA_64 test machine (Itanium-2 1.6 GHz) running a benchmark like netperf's
      UDP streaming test, the added overhead results in a drop of 3% in
      throughput, as udp_sendmsg calls the local_bh_enable/disable several times.
      
      Other workloads that have heavy usages of local_bh_enable/disable could
      also be affected.  The patch ideally should not have affected IA-64
      performance as it does not have IRQ tracing support.  A significant portion
      of the overhead is in the added irq flags save and restore, which I think
      is not needed if IRQ tracing is unused.  A suggested patch is attached
      below that recovers the lost performance.  However, the "ifdef"s in the
      patch are a bit ugly.
      Signed-off-by: NTim Chen <tim.c.chen@intel.com>
      Acked-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      3c829c36
    • C
      [PATCH] cpu hotplug: replace __devinit* with __cpuinit* for cpu notifications · 8c78f307
      Chandra Seetharaman 提交于
      Few of the callback functions and notifier blocks that are associated with cpu
      notifications incorrectly have __devinit and __devinitdata.  They should be
      __cpuinit and __cpuinitdata instead.
      
      It makes no functional difference but wastes text area when CONFIG_HOTPLUG is
      enabled and CONFIG_HOTPLUG_CPU is not.
      
      This patch fixes all those instances.
      Signed-off-by: NChandra Seetharaman <sekharan@us.ibm.com>
      Cc: Ashok Raj <ashok.raj@intel.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      8c78f307
  11. 15 7月, 2006 1 次提交
  12. 11 7月, 2006 1 次提交
  13. 04 7月, 2006 2 次提交
  14. 28 6月, 2006 2 次提交
  15. 26 6月, 2006 1 次提交
  16. 26 4月, 2006 2 次提交
  17. 22 3月, 2006 1 次提交
    • A
      [PATCH] on_each_cpu(): disable local interrupts · 78eef01b
      Andrew Morton 提交于
      When on_each_cpu() runs the callback on other CPUs, it runs with local
      interrupts disabled.  So we should run the function with local interrupts
      disabled on this CPU, too.
      
      And do the same for UP, so the callback is run in the same environment on both
      UP and SMP.  (strictly it should do preempt_disable() too, but I think
      local_irq_disable is sufficiently equivalent).
      
      Also uninlines on_each_cpu().  softirq.c was the most appropriate file I could
      find, but it doesn't seem to justify creating a new file.
      
      Oh, and fix up that comment over (under?) x86's smp_call_function().  It
      drives me nuts.
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      78eef01b
  18. 07 11月, 2005 1 次提交
    • H
      [PATCH] cpu hoptlug: avoid usage of smp_processor_id() in preemptible code · a4c4af7c
      Heiko Carstens 提交于
      Replace smp_processor_id() with any_online_cpu(cpu_online_map) in order to
      avoid lots of "BUG: using smp_processor_id() in preemptible [00000001]
      code:..." messages in case taking a cpu online fails.
      
      All the traces start at the last notifier_call_chain(...) in kernel/cpu.c.
      Since we hold the cpu_control semaphore it shouldn't be any problem to access
      cpu_online_map.
      
      The reason why cpu_up failed is simply that the cpu that was supposed to be
      taken online wasn't even there.  That is because on s390 we never know when a
      new cpu comes and therefore cpu_possible_map consists of only ones and doesn't
      reflect reality.
      Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      a4c4af7c
  19. 13 9月, 2005 1 次提交
  20. 31 7月, 2005 1 次提交
  21. 29 7月, 2005 1 次提交
  22. 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