It's a real-time circus out there!

[GMaq]

@rncbc

Hello! I asked elsewhere about rtcirqus and PipeWire and it seems this is of no added benefit to PipeWire's recent IRQ prioritizing, should I assume that your 2024 update to rtirq-init also is of not of direct benefit on systems using PipeWire (and pipewire-jack)?

[rncbc]

hi @GMaq

my rationale goes like it does matter in any case, whether or not pipewire is handling the alsa usb-audio cards on irqs (pro-audio profile) or soft-timers (as it used to before v1.0.0 came along...)

as a side note, please have a look to this additional comment on today's rtirq update.

cheers

[GMaq]

hi @GMaq

my rationale goes like it does matter in any case, whether or not pipewire is handling the alsa usb-audio cards on irqs (pro-audio profile) or soft-timers (as it used to before v1.0.0 came along...)

as a side note, please have a look to this additional comment on today's rtirq update.

cheers

Ok, good to know, thank you!

Next stupid question: I'm well versed with threadirqs and that's what I ship in AVL.. Does all of this rtirq goodness also respond to "preempt=full" on modern kernels?

[Audiojunkie]

hi @GMaq

my rationale goes like it does matter in any case, whether or not pipewire is handling the alsa usb-audio cards on irqs (pro-audio profile) or soft-timers (as it used to before v1.0.0 came along...)

as a side note, please have a look to this additional comment on today's rtirq update.

cheers

Ok, good to know, thank you!

Next stupid question: I'm well versed with threadirqs and that's what I ship in AVL.. Does all of this rtirq goodness also respond to "preempt=full" on modern kernels?

As I understand it, the preempt=full kernel parameter tells the generic kernel to run like a realtime kernel--in other words, it allows it to run with full preempt capability. The threadirqs kernel parameter goes further and splits the irqs into threads, which allows rtirq to be able to prioritize specific threads (such as the audio or USB sound card). A realtime kernel has both the preempt and the threadirqs activated internally. A generic kernel needs to have both activated to achieve a similar real time functionality. The part I'm not clear on is whether there is any interdependency between these two kernel parameters. I just know that it's always best to have both of them configured in your boot manager to achieve performance similar to the kernel that is compiled for real time functionality.

[rncbc]

you need a PREEMPT_DYNAMIC configured kernel to get preempt=full to take effect, which in fact leads to a what was known as a low-latency kernel previously (PREEMPT).

[bluebell]

you need a PREEMPT_DYNAMIC configured kernel to get preempt=full to take effect, which in fact leads to a what was known as a low-latency kernel previously (PREEMPT).

On my kernel it looks like:

Code: Select all

hm@bubu:/boot$ grep PREEMPT config-5.15.134 
# CONFIG_PREEMPT_NONE is not set
# CONFIG_PREEMPT_VOLUNTARY is not set
CONFIG_PREEMPT=y
CONFIG_PREEMPT_COUNT=y
CONFIG_PREEMPTION=y
CONFIG_PREEMPT_DYNAMIC=y
CONFIG_PREEMPT_RCU=y
CONFIG_HAVE_PREEMPT_DYNAMIC=y
CONFIG_PREEMPT_NOTIFIERS=y
CONFIG_DRM_I915_PREEMPT_TIMEOUT=640
# CONFIG_DEBUG_PREEMPT is not set
# CONFIG_PREEMPT_TRACER is not set
# CONFIG_PREEMPTIRQ_DELAY_TEST is not set

Code: Select all

hm@bubu:~$ cat /proc/cmdline 
BOOT_IMAGE=/vmlinuz-5.15.134 root=/dev/mapper/bubu--vg-root ro threadirqs quiet splash mitigations=off acpi_irq_nobalance nowatchdog nohz=off intel_idle.max_cstate=1 usbcore.autosuspend=-1 vt.handoff=7

This kernel loves rtirq.