[patch] preempt-smp.patch, 2.6.8-rc3-mm2

From: Ingo Molnar (mingo_at_elte.hu)
Date: 08/09/04

  • Next message: Dave Jones: "Re: [PATCH] - Initial dothan speedstep support" 
    Date:	Mon, 9 Aug 2004 16:01:03 +0200
To: Andrew Morton <akpm@osdl.org>

    * Ingo Molnar <mingo@elte.hu> wrote:

    > i believe we should 'ignore' SMP spinlock starvation for now: it will
    > be fixed in a natural way with the most-spinlocks-are-mutexes
    > solution, with that approach all preemption wishes of other CPUs are
    > properly expressed in terms of need_resched().
    >
    > alternatively the 'release the lock every 128 iterations and do a
    > cpu_relax()' hack could be used - but i think that doesnt solve the
    > SMP issues in a sufficient way.

    i've attached preempt-smp.patch (against 2.6.8-rc3-mm) which cleans up
    most of these scheduling issues. It does the loop counting within
    cond_resched_lock(). [and uninlines those functions for smaller
    footprint.]

    [ the loop counter is free-running so the counts of different loops get
    concatenated - this is not a big issue and i dont think we want to touch
    the loop counter every time we disable preemption (or enter a loop). ]

    this patch in essence recognizes the fact that the current preemption
    design is broken on SMP. It works the issue around by adding the polling
    component to need_resched_lock(). These loop-checks used to be
    open-coded in quite ugly ways.

    the patch shows all the variants that occur typically: locked loop that
    can be broken without state worries, and locked loops that need to
    modify state to preempt safely.

    the patch also fixes all the open-coded paths that did either
    loop-counting or need-resched-checking and fixes a number of bugs that
    occur with such open-coding: either the loop-counting or the
    need-resched checking was missing.

    once the need_resched() problem is solved cleanly by using mutexes for
    all exclusion activity on SMP, this polling component can be removed.

    i've tested the patch on x86 UP and SMP. (CONFIG_PREEMPT enabled.)

            Ingo

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  • Next message: Dave Jones: "Re: [PATCH] - Initial dothan speedstep support"

    Relevant Pages

    • Re: Packet loss every 30.999 seconds
      ... The patch should work fine. ... It patches the bottom of the loop, which is only reached if the vnode ... So it will only help if there are thousands of dirty vnodes. ... the main problem is to figure out why PREEMPTION doesn't work. ...
      (freebsd-net)
    • Re: Packet loss every 30.999 seconds
      ... The patch should work fine. ... It patches the bottom of the loop, which is only reached if the vnode ... So it will only help if there are thousands of dirty vnodes. ... the main problem is to figure out why PREEMPTION doesn't work. ...
      (freebsd-stable)
    • Re: [linux-audio-dev] Re: [announce] [patch] Voluntary Kernel Preemption Patch
      ... > I'd prefer that we find a solution for SMP too though. ... i have solved the fundamental SMP latency problems in the -Q7 patch, ... redesigning how SMP preemption is done. ... the main change in this patch are more SMP latency fixes. ...
      (Linux-Kernel)
    • wait_event and preemption in 2.6
      ... I'm writing a device driver for PPC Linux and I'm using wait_event. ... preemption is turned on. ... check the condition and break out of the loop. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: [PATCH][resubmit] x86: enable preemption in delay
      ... The difference is that in Steven's version the loop is running ... mainly with preemption disabled, except for: ... set the mask of allowed cpus to the current cpu only; ...
      (Linux-Kernel)