https://bugzilla.novell.com/show_bug.cgi?id=579932
https://bugzilla.novell.com/show_bug.cgi?id=579932#c149
--- Comment #149 from Mike Galbraith
(In reply to comment #147)
Well, that's kind of a trick question. A PREEMPT kernel can handle that depending on hardware/firmware and how tight your jitter tolerance is. My old Q6600 box running a PREEMPT/250 Hz kernel can easily meet a 1KHz periodic demand even under hefty load iff I don't expect too much worst case wise.
Hehe, I think this is exactly the problem: reportedly, current kernel leads to "degraded music playback and gaming quality".
And yep, it must very well be hardware/firmware-dependent because audio runs just fine on my box here, even under heavy load (I don't play games :-)).
Here too. 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 ;-) 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.
On an isolated core as below, I can expect a whole lot more..
Hmm, I was wondering whether NO_HZ_FULL would help even on an SMI-plagued hw? That would be an interesting thing to try.
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...
jitter: 22.54 min: 5.12 max: 27.66 mean: 16.41 stddev: 0.71 18 > 25 us hits min: 26.42 max: 27.66 mean: 26.89 stddev: 0.31
..but above, you can plainly see where I killed the cpuhog that was keeping CPU3 away from cstates. The firmware on this box is ok (no SMI),
How am I to read this? As in "jitter grows when the core is allowed to go in deeper C-states?"
Yeah.
but the core2 CPU itself isn't particularly wonderful.
Why? I don't think the CPU itself has any fault in this - it is the glue around it which makes it misbehave, like C-states and such. If you keep it powered on throughout with idle=poll, for example, C-states influence should be gone. I even heard RT-folk do that in certain cases.
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 ;-) An Intel guy told me core2 had latency issues, maybe he was talking about glue, dunno. 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... -- 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.