Re: [LAU] More recent kernel config options

Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
To: Brent Busby <brent@...>
Cc: Linux Audio User <linux-audio-user@...>
Date: Sunday, July 26, 2009 - 9:24 pm

On Sat, 25 Jul 2009, Brent Busby wrote:

> In addition to the question I posted earlier about PREEMPT_RCU, I've

I tried out the 64Studio stable version last fall, and had a lot of troubles
with it. The 2.6.21 based kernel wouldn't even boot on my box, so I ended up
booting up with the 2.6.24 based -rt kernel that I was using on Fedora 8 /
CCRMA. There were too many libraries and apps that were way too out of date
for my tastes, so I abandoned the whole experiment.

> I might as well collate these questions here, for what good it may do.

There was a time when PREEMPT_RCU was unstable, and most of the -rt kernel
releases would fix one RCU bug while adding another. These times are now past,
however. PREEMPT_RCU has been completely stable for me on AMD and Intel (both
multicore) for about a year now.


Here's another vote for completely broken! Every time I set up a box with the
-rt kernel, I start with the distro's .config and tweak from there. And every
time, I can't make realtime low-latency audio a reality until I disable


As far as I can tell, CGROUPS doesn't affect realtime latencies enough to make
any sort of difference for realtime audio. It does, however, mess with the
scheduler, even without setting up the affinity groups. I've noted some
strange scheduling behavior: When running multiple instances of the same CPU
bound task (like burnP6, mprime, dd, or your favorite stress tester), the tasks
usually start off fairly evenly distributed between the cores, and then the
affinity seems to drift, lumping these tasks on one half of the cores while
leaving the other half mostly idle. On a core2quad with CGROUPS enabled, I
generally have to run 12 instances of burnP6 to keep utilization of all four
cores pegged at 99-100%. I wouldn't go as far as to say that CGROUPS is
broken, but I fail to see the usefulness on a production audio system with the
IRQ and other realtime priorities tuned properly, especially now that the core
scheduling features for -rt are stable.

> --

I've also run into a handful of config options that either help or hurt
realtime performance, depending on the specific hardware:

NO_HZ (seems to work properly on most hardware these days)
PCI_MSI (some PCI devices seem to add more latency with MSI)
RTC_DRV_CMOS (this depends on your particluar RTC hardware)
HPET_EMULATE_RTC (this depends on your particluar HPET hardware)
X86_ACPI_CPUFREQ (creates TSC drift between cores on Intel)

And of course, there's all kinds of profiling, stats, testing, and debugging
options that make any realtime load suffer. Occasionally, you'll find a device
driver that's just plain bad for -rt performance, but I've been running into
this problem a lot less these days.

Equally as important for low-latency are the scheduling priorities. After a lot
of google, lkml, and trial and error, I've settled on the following for
rock-solid low-latency audio:

99 FF migration
99 FF posixcputmr
98 FF IRQ-8 (realtime clock)
97 FF audio IRQ (in some cases means ieee1394 or specific USB port)

All audio and MIDI apps should run at a lower realtime priority than JACK. All
other IRQ- and sirq- threads should be set to
SCHED_OTHER. To set this up, I've added the following to my /etc/rc.local:

# set all irq threads to sched_other
for irq in `pgrep 'IRQ-'`; do
chrt -o -p 0 $irq;

# set all softirq threads to sched_other
for sirq in `pgrep 'sirq-'`; do
chrt -o -p 0 $sirq;

# set high prio IRQs
chrt -f -p 98 `pgrep IRQ-8` # rtc
chrt -f -p 97 `pgrep IRQ-16` # hda-intel

And of course, there's those pesky BIOS options. Some of the newer Intel CPU
features like to generate interrupts that the kernel can do absolutely nothing
about. I had to disable C1E, CPU TM function, execute disable bit, and one of
the ACPI options (can't remember which one) to get my core2quad to work.
Disabling video interrupts (only an issue on older hardware) always seems to
help. AMD systems seem to require much less (if any) BIOS tweaking for -rt.

Please, anyone, correct me if I'm wrong on any of this. Most of this knowledge
is gained from four years of following -rt development and tuning -rt kernels
on a variety of hardware. I'm always adding to my bag of tricks when it comes
to tuning realtime machines ;-}

Linux-audio-user mailing list

Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]

Messages in current thread:
Re: [LAU] More recent kernel config options, William Weston, (Sun Jul 26, 9:24 pm)
Re: [LAU] More recent kernel config options, Ken Restivo, (Mon Jul 27, 12:03 am)
Re: [LAU] More recent kernel config options, William Weston, (Mon Jul 27, 1:44 am)
Re: [LAU] More recent kernel config options, Brent Busby, (Mon Jul 27, 12:41 am)
Re: [LAU] More recent kernel config options, William Weston, (Mon Jul 27, 1:54 am)