Messages in this thread | ![/](/images/icornerl.gif) | | Date | Wed, 15 Sep 2004 10:29:56 +0100 (WEST) | Subject | Re: [patch] voluntary-preempt-2.6.9-rc1-bk12-R5 | From | "Rui Nuno Capela" <> |
| |
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/
| ![\](/images/icornerr.gif) |