https://bugzilla.novell.com/show_bug.cgi?id=579932
https://bugzilla.novell.com/show_bug.cgi?id=579932#c152
--- Comment #152 from Borislav Petkov
If it's _not_ one of those crippled up hpet inflicted boxen (can't help at all there), I'd fire up tracer with wakeup_rt tracer and see what's going on if an rt task doesn't hit the CPU in short order. A full ms wakeup latency is definitely not considered to be in short order for an rt task ;-)
Ok.
You can forget that 100us constraint though, it's not really achievable under load with a non-rt kernel, and certainly not when you add tracing overhead on top. If THP is on, turn that off (I traced
600us held in kernel by that in NOPREEMPT kernel iirc), and run some normal load where sound doesn't play well.
Well, I'd still like to stay within the reasonable here since it is the stock kernel and we're talking about audio (I'm not saying RT folk is unreasonable :-)). If it can stomach higher latencies without becoming noticeable, then we're fine.
There's nothing at all you can do for SMIs afaik, unless your BIOS will let you turn the darn things off. My core2 box won't even enter tickless mode. Per Frederic, the unstable tsc precludes that. Booting tsc=reliable didn't help though...
That's impossible since the TSC halts in a C-state and if HPET is using SMM (or SMM is happening anyway because some idiotic vendors decided to do power management in it; oh, and with UEFI we'll be entering the BIOS even more, <pukes>) then you're right, no way we can avert SMM.
Ok, the combo of old core2 cpu and its associated old glue isn't wonderful for rt. I have no idea what specific silicon gnomes in specific cubicles do from 9 to 5 ;-)
I think we're better off if we never know. (I'm trying hard to forget some stuff I saw :-)).
An Intel guy told me core2 had latency issues, maybe he was talking about glue, dunno.
Yeah, probably.
Funny thing with my core2 box is just keeping it away from cstates isn't enough, it has to be kept kept churning and burning to eliminate the idle jitter. Hohum, kind off topic, but mentioned wrt that 100us thing, it all contributes, and as you can see from my box, a substantial chunk of that unofficial, but frequently mentioned and pulled out of thin air, target latency number is pre-consumed. If I don't set cpufreq to performance, there goes a bunch more. Add nohz, etc etc...
Hmm, ok, I think I can see what the latency issues could be: C-states entry and exit need to do a bunch of stuff behind the scenes, architecture-wise, and there you can have your possible delays. That's why you want to keep your cores in C0 - no idle entry at all. Thanks. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.