Re: Attempted summary of "RT patch acceptance" thread

[Andrea Arcangeli <andrea@suse.de>]

On Tue, Jun 14, 2005 at 09:09:39AM -0700, Gerrit Huizenga wrote:
> RT code should be crafted so that every single laptop user is running
> most of the code *and* benefiting from it.  If most of the RT code goes

The problem is that it's not feasible to enable it by default and
pretend not to hurt the larger part of the userbase.

Only the musicians and the videogame players may get a benefit from
preempt-RT (probably the videogames players may not get a noticeable
benefit either), everyone else would be hurt somehow.

I don't think it's correct to compare this to the smp scalability
effort, where even a small 2-way was getting benefit from every SMP
optimization done for a 16-way.

Also don't forget today UP systems still run with CONFIG_SMP disable to
keep performance of those systems higher (that may change once UP
systems becomes obsolete, but not because CONFIG_SMP is useless per se ;).

The RT design emulates infinite cpus, with the associated locking
contention that infinite cpus would generate (actually the number is
bound at some point, it's not really infinite but it depends on the
hardware/software combination). To make things even worse every
contention (even if short) generates overscheduling. So the performance
impact of some workload is probably going to be very measurable for a
small system that has no need of dealing with the infinite-cpus locking.
Some slowdown number have been posted already, but probably debug
options were enabled and there's room for further optimization, they
seemed excessive bad numbers so far which can be improved, but no idea
how much.

The mouse going faster kind of thing must be always verified with a
placebo to give it any statistical value (if it cannot be measured),
otherwise by applying the new feature it'll always go faster with the
new feature applied, it happened to me as well sometime, humans aren't
very reliable since our (or at least my) perception of time vary
depending on the feelings.

To make an example I'm 100% sure that I would only get downsides by
running preempt-RT in all my production systems (including laptops,
desktop and servers), so while I may run it on my test systems to help
testing, I would never consider to enable it on any of my production
systems where I try to keep an optimal setup. This has never been the
case with the smp scalability effort, I've always got benefits in all my
smp systems, and I had CONFIG_SMP=n in the UP systems.

This is why there's a config option for preempt-rt I think, which makes
perfect sense to me and I doubt it'll be enabled by default, at least
unless they find a way to reduce the slowdown to not-measurable levels,
which I strongly doubt, especially due the irq scheduling thingy.

Perhaps the only thing that I could benefit from is such horrible 8msec
latency of the usb irq in my firewall, but that's a bug that needs
fixing by offloading it to softirq or in some other way, preempt-RT
would only hide the real problem at the expense of overscheduling.

non-RT irqs are always supposed to be as quick as possible and to do the
processing in normal kernel context after a wakeup (or softirq context
after posting a tasklet or raising a softirq, or even a kevent).

Overall I doubt preempt-RT config option objective was to be enabled by
default in the kernel that gets installed on laptops, but I could be
wrong.