nhorman
commented
1 month ago Its probably just simpler to map IRQ_OTHER to the cache level universally, you can try with this patch:
--- a/classify.c
+++ b/classify.c
@@ -26,7 +26,7 @@ char *classes[] = {
};
static int map_class_to_level[8] =
-{ BALANCE_PACKAGE, BALANCE_CACHE, BALANCE_CORE, BALANCE_CORE, BALANCE_CORE, BALANCE_CORE, BALANCE_CORE, BALANCE_CORE };
+{ BALANCE_CACHE, BALANCE_CACHE, BALANCE_CORE, BALANCE_CORE, BALANCE_CORE, BALANCE_CORE, BALANCE_CORE, BALANCE_CORE };If it works for you ,feel free to open a PR for it.
Though, This isn't really a problem about picking the best balance level, its more a inherent problem with identifying what these platform devices are (or more specifically, what their interrupt volume is going to be), and theres no good solution for that, save for a policy script
Take a look at your debug output. You have about 100 irqs there. two of them have over 100k events on them (likely ethernet devices). two have a few thousand (probably some gpio bus or some such), and 3 have a few hundred (maybe serial ports or other low throughput io). The rest have no volume at all. What irqbalance should do is place the first two on their own cores, place the second two at the cache level, and honestly, depending on the use case, just leave the rest of them alone, or affine them to the package level, because selecting anything more specific is effectively a no-op, as their not impacting cpu usage at all.
Even if the patch above makes your life a bit easier, you're going to want to write a policy script that isolates the high volume interrupts above, and either balances them at the appropriate level, or masks them from irqbalance entirely and manually sets their affinity to the core you want, depending on how specific you want to be.
sean-anderson-seco
I am running irqbalance on an embedded system, where the vast majority of interrupts are from platform devices. irqbalance makes an attempt to classify IRQs based on their name (
guess_arm_irq_hints). However, this is generally ineffective because:/sys/devices/platform/(such as if it is on another bus)net4, net5, net6, net7)Because of all these reasons, the heuristics used by irqbalance generally just result in the default of
IRQ_TYPE_LEGACY/IRQ_OTHER. Although this does not correctly identify the type of interrupt, it might have been fine except that all CPUs are in a single package and cache domain. BecauseIRQ_OTHERinterrupts default toBALANCE_PACKAGE, no balancing is performed at all! This may be remedied using a scriptbut the default behavior remains useless and confusing (since you could get the same result without running IRQbalance at all).
I think the best way to fix this would be to make the balance level for
IRQ_OTHERdefault to the highest balance level with things to balance between. E.g. on a system with one package and two cache domains with four CPUs each, it would default toBALANCE_CACHE. On a system with one package, one cache domain, and three CPUs it would default toBALANCE_CORE.I think it also would be nice to be able to specify the balance level for
IRQ_OTHERinterrupts via a command-line option, but this would still leave undesirable default behavior.