Re: RT patch acceptance

Sven-Thorsten Dietrich
2005-05-25T18:00:51Z

On Wed, 2005-05-25 at 19:17 +0200, Andi Kleen wrote:
> Ingo Molnar <mingo@elte.hu> writes:
>
> > * Andrew Morton <akpm@osdl.org> wrote:
> >
> >> Sven Dietrich <sdietrich@mvista.com> wrote:
> >> >
> >> > I think people would find their system responsiveness / tunability
> >> > goes up tremendously, if you drop just a few unimportant IRQs into
> >> > threads.
> >>
> >> People cannot detect the difference between 1000usec and 50usec
> >> latencies, so they aren't going to notice any changes in
> >> responsiveness at all.
> >
> > i agree in theory, but interestingly, people who use the -RT branch do
> > report a smoother desktop experience. While it might also be a
>
> I bet if you did a double blind test (users not knowing if they
> run with RT patch or not or think they are running with patch when they
> are not) they would report the same.
>

I would take that bet double or nothing.

> Basically when people go through all that effort of applying
> a patch
You mean typing "patch -p1 < ..."

> then they really want to see an improvement. If it is there
> or not.
>

Hopefully they will also set the config options correctly :)

> You surely have seen that with other patches when users
> suddenly reported something worked better/smoother with a new
> release etc and there was absolutely no explanation for it in the changed
> code.
>

I suppose the audio guys have something on that.
Even if you don't have an ear for music, you can hear a
skip on a CD, a scratch on a record, or a glitch on
a digital audio file from preemption latency.

These are all events in the same time frame, and
that is in the milliseconds....

> I have no reason to believe this is any different with all
> this RT testing.
>

And that's why we have been testing and benchmarking, to
produce number sets that supersede faith, belief, and
conjecture. But ultimately, you can trust your senses,
and I think the audio / video test would allow your eyes
to see, and your ears to hear the difference.

> -Andi (who also would prefer to not have interrupt threads, locks like
> a maze and related horribilities in the mainline kernel)

I am definitely for breaking out an IRQ threads patch,
separate from the RT-mutex patches, even if just to
allow examination of that code without the clutter.