Re: RT patch acceptance

[Steven Rostedt <rostedt@goodmis.org>]

On Wed, 2005-05-25 at 19:17 +0200, Andi Kleen wrote:
> 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. 
> 

The double blind is a bad idea. It puts perceptions in the head where
they may say they see no improvement when there is.

A better test would be to have two identical computers running side to
side (say computer A and B). Let a number of people play around with
both for a while, with web browsing, movie viewing, mp3 listening, etc.
And then have a survey of which machine performed better and general
comments.  Don't let them even know about the RT patch, although one
would have it and the other would not.  That would probably be the best
indication of whether or not the patch is noticeable.  If everyone
(>85%) says that computer A is much smoother in running video or sound,
and computer A had the RT patch, then the answer would be yes.  But if A
didn't, or there was no notice of a difference (~50% say A and ~50% say
B), then you can say there is no notice of difference with the patch.


> Basically when people go through all that effort of applying
> a patch then they really want to see an improvement. If it is there
> or not.

So make it mainline, and then they won't need to go through any effort
in applying the patch :-)

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

Yes, but these changes are part of the code.

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

Maybe not for the average user noticing the differences, but Lee's
latency tests seem to show something.

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

Why is it so horrible to have interrupts as threads?  It's just a config
option and it really doesn't complicate the kernel that much.  As for
the maze in the locks, the spin_locks are already pretty confusing with
out the changes, and the confusion with them is just to keep the
interface the same.  I actually like the way Ingo did the locks. I use
to work for TimeSys and if you wanted to use a raw_spinlock in their
kernel you needed to always explicitly call raw_spin_lock and
raw_spin_unlock.  The macros with Ingo's makes it easy to switch between
the raw and mutex spin lock.

-- Steve


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