11 Oct, 2007

2 commits


18 Jul, 2007

1 commit

  • 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: Rafael J. Wysocki
    Acked-by: Nigel Cunningham
    Cc: Pavel Machek
    Cc: Oleg Nesterov
    Cc: Gautham R Shenoy
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Rafael J. Wysocki
     

17 Jul, 2007

1 commit

  • Fix ksoftirqd termination on cpu hotplug with naughty real time process.

    Assuming the following case:

    - Try to hot remove CPU2 from CPU1.
    - There is a real time process on CPU2, and that process doesn't sleep at all.
    - That rt process and ksoftirqd/2 is migrated to the CPU0

    Then ksoftirqd/2 can't stop becasue that rt process runs everlastingly on
    CPU0, and CPU1 waiting the ksoftirqd/2's termination hangs up. To fix this
    problem, set the priority of ksoftirqd/2 to max one before kthread_stop().

    [akpm@linux-foundation.org: fix warning]
    Signed-off-by: Satoru Takeuchi
    Cc: Rusty Russell
    Cc: Ingo Molnar
    Cc: Oleg Nesterov
    Cc: Ashok Raj
    Cc: Gautham R Shenoy
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Satoru Takeuchi
     

10 Jul, 2007

1 commit

  • do not set softirqs to nice +19. _If_ for whatever reason
    we missed to process some high-prio softirq and woke up
    ksoftirqd, we should give it a fair chance to actually
    get some work done, even if the system is under load.

    Signed-off-by: Ingo Molnar

    Ingo Molnar
     

10 May, 2007

1 commit

  • 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: Rafael J. Wysocki
    Cc: Gautham R Shenoy
    Cc: Pavel Machek
    Signed-off-by: Oleg Nesterov
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Rafael J. Wysocki
     

17 Feb, 2007

2 commits

  • With Ingo Molnar

    Add functions to provide dynamic ticks and high resolution timers. The code
    which keeps track of jiffies and handles the long idle periods is shared
    between tick based and high resolution timer based dynticks. The dyntick
    functionality can be disabled on the kernel commandline. Provide also the
    infrastructure to support high resolution timers.

    Signed-off-by: Thomas Gleixner
    Signed-off-by: Ingo Molnar
    Cc: john stultz
    Cc: Roman Zippel
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Thomas Gleixner
     
  • Uninline irq_enter(). [dynticks adds more stuff to it]

    No functional changes.

    Signed-off-by: Ingo Molnar
    Signed-off-by: Thomas Gleixner
    Cc: john stultz
    Cc: Roman Zippel
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Ingo Molnar
     

08 Dec, 2006

1 commit

  • 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: Zachary Amsden
    Cc:
    Cc: Ingo Molnar
    Cc:
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Zachary Amsden
     

30 Sep, 2006

1 commit

  • Spawing ksoftirqd, migration, or watchdog, and calling init_timers_cpu()
    may fail with small memory. If it happens in initcalls, kernel NULL
    pointer dereference happens later. This patch makes crash happen
    immediately in such cases. It seems a bit better than getting kernel NULL
    pointer dereference later.

    Cc: Ingo Molnar
    Signed-off-by: Akinobu Mita
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Akinobu Mita
     

01 Aug, 2006

2 commits

  • 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=de30a2b355ea85350ca2f58f3b9bf4e5bc007986

    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: Tim Chen
    Acked-by: Ingo Molnar
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Tim Chen
     
  • 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: Chandra Seetharaman
    Cc: Ashok Raj
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Chandra Seetharaman
     

15 Jul, 2006

1 commit

  • Christoph Hellwig:
    open_softirq just enables a softirq. The softirq array is statically
    allocated so to add a new one you would have to patch the kernel. So
    there's no point to keep this export at all as any user would have to
    patch the enum in include/linux/interrupt.h anyway.

    Signed-off-by: Adrian Bunk
    Acked-by: Ingo Molnar
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Adrian Bunk
     

11 Jul, 2006

1 commit


04 Jul, 2006

2 commits

  • At the moment, powerpc and s390 have their own versions of do_softirq which
    include local_bh_disable() and __local_bh_enable() calls. They end up
    calling __do_softirq (in kernel/softirq.c) which also does
    local_bh_disable/enable.

    Apparently the two levels of disable/enable trigger a warning from some
    validation code that Ingo is working on, and he would like to see the outer
    level removed. But to do that, we have to move the account_system_vtime
    calls that are currently in the arch do_softirq() implementations for
    powerpc and s390 into the generic __do_softirq() (this is a no-op for other
    archs because account_system_vtime is defined to be an empty inline
    function on all other archs). This patch does that.

    Signed-off-by: Paul Mackerras
    Signed-off-by: Ingo Molnar
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Paul Mackerras
     
  • Accurate hard-IRQ-flags and softirq-flags state tracing.

    This allows us to attach extra functionality to IRQ flags on/off
    events (such as trace-on/off).

    Signed-off-by: Ingo Molnar
    Signed-off-by: Arjan van de Ven
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Ingo Molnar
     

28 Jun, 2006

2 commits

  • This patch reverts notifier_block changes made in 2.6.17

    Signed-off-by: Chandra Seetharaman
    Cc: Ashok Raj
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Chandra Seetharaman
     
  • In 2.6.17, there was a problem with cpu_notifiers and XFS. I provided a
    band-aid solution to solve that problem. In the process, i undid all the
    changes you both were making to ensure that these notifiers were available
    only at init time (unless CONFIG_HOTPLUG_CPU is defined).

    We deferred the real fix to 2.6.18. Here is a set of patches that fixes the
    XFS problem cleanly and makes the cpu notifiers available only at init time
    (unless CONFIG_HOTPLUG_CPU is defined).

    If CONFIG_HOTPLUG_CPU is defined then cpu notifiers are available at run
    time.

    This patch reverts the notifier_call changes made in 2.6.17

    Signed-off-by: Chandra Seetharaman
    Cc: Ashok Raj
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Chandra Seetharaman
     

26 Jun, 2006

1 commit

  • If a cpu hotplug callback fails on CPU_UP_PREPARE, all callbacks will be
    called with CPU_UP_CANCELED. A few of these callbacks assume that on
    CPU_UP_PREPARE a pointer to task has been stored in a percpu array. This
    assumption is not true if CPU_UP_PREPARE fails and the following calls to
    kthread_bind() in CPU_UP_CANCELED will cause an addressing exception
    because of passing a NULL pointer.

    Signed-off-by: Heiko Carstens
    Cc: Ashok Raj
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Heiko Carstens
     

26 Apr, 2006

2 commits

  • Few of the notifier_chain_register() callers use __init in the definition
    of notifier_call. It is incorrect as the function definition should be
    available after the initializations (they do not unregister them during
    initializations).

    This patch fixes all such usages to _not_ have the notifier_call __init
    section.

    Signed-off-by: Chandra Seetharaman
    Signed-off-by: Linus Torvalds

    Chandra Seetharaman
     
  • Few of the notifier_chain_register() callers use __devinitdata in the
    definition of notifier_block data structure. It is incorrect as the
    data structure should be available after the initializations (they do
    not unregister them during initializations).

    This was leading to an oops when notifier_chain_register() call is
    invoked for those callback chains after initialization.

    This patch fixes all such usages to _not_ have the notifier_block data
    structure in the init data section.

    Signed-off-by: Chandra Seetharaman
    Signed-off-by: Linus Torvalds

    Chandra Seetharaman
     

22 Mar, 2006

1 commit

  • 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: Andrew Morton
    Signed-off-by: Linus Torvalds

    Andrew Morton
     

07 Nov, 2005

1 commit

  • 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: Heiko Carstens
    Cc: Ingo Molnar
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Heiko Carstens
     

13 Sep, 2005

1 commit


31 Jul, 2005

1 commit


29 Jul, 2005

1 commit


17 Apr, 2005

1 commit

  • 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!

    Linus Torvalds