[patch] voluntary-preempt-2.6.9-rc1-bk4-Q7

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

  • Next message: Peter Astrand: "Re: ncpfs problems" 
    Date:	Wed, 1 Sep 2004 15:51:22 +0200
To: linux-kernel@vger.kernel.org

    i've released the -Q7 patch:

      http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.9-rc1-bk4-Q7

    ontop of:

      http://redhat.com/~mingo/voluntary-preempt/diff-bk-040828-2.6.8.1.bz2

    the main change in this patch are more SMP latency fixes. The stock
    kernel, even with CONFIG_PREEMPT enabled, didnt have any spin-nicely
    preemption logic for the following, commonly used SMP locking
    primitives: read_lock(), spin_lock_irqsave(), spin_lock_irq(),
    spin_lock_bh(), read_lock_irqsave(), read_lock_irq(), read_lock_bh(),
    write_lock_irqsave(), write_lock_irq(), write_lock_bh(). Only
    spin_lock() and write_lock() [the two simplest cases] where covered.

    In addition to the preemption latency problems, the _irq() variants in
    the above list didnt do any IRQ-enabling while spinning - possibly
    resulting in excessive irqs-off sections of code!

    -Q7 fixes all of these latency problems: we now re-enable interrupts
    while spinning in all possible cases, and a spinning op stays
    preemptible if this is a beginning of a new critical section.

    there's also an SMP related tracing improvement in -Q7: the NMI tracing
    code now traces the other CPUs too - this way if an NMI hits a
    particulary long section, we'll have a chance to see what the other CPU
    was doing. These show up as double do_nmi() trace entries on a 2-CPU x86
    box. The first one is the current CPU, subsequent entries are the other
    CPUs in the system.

    (-Q7 is not that interesting to uniprocessor kernel users, but it would
    still be useful to test it, just to see nothing broke (on the
    compilation side), lots of spinlock code had to be changed.)

            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: Peter Astrand: "Re: ncpfs problems"

    Relevant Pages

    • Re: 16-Node Parallel System
      ... > We need a cost-effective 16-Node compute cluster for Academic ... Then you use any O/S kernel that is SMP aware, ... additional CPUs are added to the node). ... the interconnect of a SMP's 16 CPU interconnect will not ...
      (comp.parallel.mpi)
    • Re: VM fixes [4/4]
      ... >> If those old cpus really supported smp in linux, then fixing this bit is ... What I meant in this specific case being UP w/o preempt is enough to be ... So the only trouble here is SMP or PREEMPT. ... will fix the alpha arch with smp or preempt enabled on older cpus too. ...
      (Linux-Kernel)
    • Re: AMD Athlon 64 X2
      ... The CPU and motherboard also work with WSeB as well. ... Note - the motherboard I purchased came with BIOS rev 1013 and you ... have to flash the BIOS with a later version to get the CPUs ... I tried all of the recent SMP kernels but no luck. ...
      (comp.os.os2.setup.misc)
    • Re: AMD Athlon 64 X2
      ... Note - the motherboard I purchased came with BIOS rev 1013 and you have to flash the BIOS with a later version to get the CPUs recognized. ... I tried all of the recent SMP kernels but no luck. ... My expectation at present would be that most Athlon X2 systems will not work with OS/2 SMP and the ones that do are likely very unstable. ...
      (comp.os.os2.setup.misc)
    • Re: vxworks6.6 : running multiple AMP instances on multicore chips
      ... (multiple instances of vxworks) ... vxworks SMP or multiple instances of vxworks AMP. ... How can I run this on multiple cpus? ... so that each core sees the same logical address space. ...
      (comp.os.vxworks)