Re: RT patch acceptance

[Sven-Thorsten Dietrich]

On Wed, 2005-05-25 at 19:17 +0200, Andi Kleen wrote:
> Ingo Molnar <mingo@xxxxxxx> writes:
> 
> > * Andrew Morton <akpm@xxxxxxxx> wrote:
> >
> >> Sven Dietrich <sdietrich@xxxxxxxxxx> 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.



-
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/