lkml.org 
[lkml]   [2004]   [Sep]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    SubjectRe: [patch] voluntary-preempt-2.6.9-rc1-bk12-R5
    From
    Hi,

    Lee Revell wrote:
    >
    >Rui Nuno Capela wrote:
    >>
    >> 8) Indeed, only by disabling both softirq and hardirq preeemption I get
    >> an usable VP+SMP kernel. But that's no surprise either, it has been
    >> always like that until Q3, which was the latest VP+SMP combination that
    >> didn't suffer with the Wacom tablet presence at boot/init time. I only
    >> hoped the (soft|hard)irq trouble would be solved by R9 time.
    >
    > Rui, did you ever get this working? Other testers are not reporting
    > problems, it would be good to know if there are still bugs lurking.
    >
    > Have you tried booting with hard and softirq preemption disabled and
    > enabling them one at a time?
    >

    I've beeing doing a lot experiments, the trial-and-error way, by tweaking
    kernel config options on and off, and (re)building the
    linux-2.6.9-rc1-bk12-S0 SMP kernel.

    I have some news indeed. As you may recall, I'm trying to run jackd
    realtime low-latency audio on a P4 2.80C HT (Hyperthreading), and I keep
    CONFIG_SMP=y always set.

    I found, almost by mistake, that whether CONFIG_SCHED_SMT is set makes a
    lot of difference.

    a) With CONFIG_SCHED_SMT=y, which I've being doing since ever, the system
    behavior is that same one I've been complaining about: having
    softirq-preempt=0 and hardirq-preempt=0 is the minimal setting to run
    jackd in realtime mode without hard-locking the whole system. Even then, I
    get the system completely frozen more times than I like, almost twice a
    day! Can't figure out who's or what's the culprit here. It's quite random.

    b) When CONFIG_SCHED_SMT is not set, I can run all along with
    softirq-preempt=1, hardirq-preempt=1 et al. While running jackd in
    realtime mode, I get NO hard-locks, but unfortunately XRUNs are plenty. A
    real storm. However I've noticed that the whole seems pretty much stable,
    as I didn't experience one single system hang. Regression to
    softirq-preempt=0 and hardirq-preempt=0 dissolves the xrun storm to
    nothing again.

    All my experiments were done based on starting jackd -R -p 128 -n 2 ...
    using an onboard Intel ICH5 soundcrap driven by snd-intel8x0 (alsa). Oh, I
    forgot to say that it's been always with kernel-preempt=1 and
    voluntary-preempt=1.

    I'm preparing to take some latency traces later on, while regarding the
    SMP=1 SMT=0 configuration and softirq=1 hardirq=1 setting, in a effort to
    let that horrible XRUN flux getting out of the way somehow, someday ;)

    So, bottomline is that the SMT-aware scheduler is not ready for VP, isn't
    it? Does anyone care to confirm this out?

    Cheers.
    --
    rncbc aka Rui Nuno Capela
    rncbc@rncbc.org

    -
    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/

    \
     
     \ /
      Last update: 2005-03-22 14:06    [W:3.662 / U:0.076 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site