Re: CONFIG_IRQBALANCE for AMD64?

[Martin J. Bligh]

> With all due respect, "it might be an embedded box" is not normally a reason why we keep stuff in the kernel.  With initramfs et. al., we are actively moving in the opposite direction.
> 
> If this was the only reason for having kirqd in the kernel, it would be long gone.
> 
> The reason why kirqd hasn't been removed is simply because nobody has stepped up to do a apples-to-apples comparison to prove that userland irqbalanced has any performance advantages, or disadvantages, over kirqd.  From a hard-numbers perspective, compared to kirqd, the userland solution is still largely an unknown quantity.
> 
> irqbalanced makes a lot of sense from a flexibility and policy perspective, and it works on multiple arches, so it has a lot more going for it.
> 
> "We like it in the kernel so we don't have to ship a userland component" is not a valid reason.

Personally, I find the argument that it's hardware-specific control code
a much better reason for it to belong in the kernel. But now it's a config
option, everyone can do what they like ... so there's no need to argue
back and forth any more. Not to say the in-kernel one doesn't need some
fixing up, but we're planning on doing that later this year.

M.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/