Re: RT patch acceptance

[Ingo Molnar]

* Nick Piggin <nickpiggin@xxxxxxxxxxxx> wrote:

> >i agree in theory, but interestingly, people who use the -RT branch do 
> >report a smoother desktop experience. While it might also be a 
> >psychological effect, under -RT an interactive X process has the same 
> >kind of latency properties as if all of the mouse pointer input and 
> >rendering was done in the kernel (like some other desktop OSs do).
> >
> >so in terms of mouse pointer 'smoothness', it might very well be 
> >possible for humans to detect a couple of msec delays visually - even 
> >though they are unable to notice those delays directly. (Isnt there some 
> >existing research on this?)
> 
> I'm guessing not, just because the monitor probably hasn't even 
> refreshed at that point ;) But...

this reminds me, people very much notice the difference between an LCD 
that has 20 msec refresh rates vs. ones that have 10 msec refresh rates.

i'd say the direct perception limit should be somewhere around 10 msec, 
but there can be indirect effects that add up. (e.g. while we might not 
be able to detect so small delays directly, the human eye can see 
_distance_ anomalies that are caused by small delays. E.g. the feeling 
of how 'smoothly' the mouse moves might be more accurate than direct 
delay perception. But i'm really out on a limb here as this is so hard 
to measure directly.)

> [...]
> >
> >[ of course this is all just talk, but people seem to have a desire to
> >  talk about it :-) ]
> >
> 
> You make good points. What's more, I don't think anyone needs to 
> advocate the RT work on the basis that it improves interactiveness.
>
> That path is just going to lead to unwinnable arguments and will 
> distract from the real measurable improvements that it does bring.
> 
> I think anyone who doesn't like that won't be convinced because 
> someone is telling them it improves interactiveness ;)

a good number of testers use it because it improves interactiveness - so 
you'll see these arguments come up.

One indirect latency effect is that during heavier VM load, e.g. kswapd 
(or the swapout code) is preemptable by X.

Another indirect effect is that in the stock kernel, interrupt work is 
not preemptable. So a short succession of heavier interrupts, followed 
by softirq processing, can very much cause more than 10 msec delays.  
Under PREEMPT_RT (or just PREEMPT + softirq and hardirq threading) these 
workloads are much more controlled. (at the price of significant IRQ 
processing overhead, which should not be ignored either.)

but ... i agree that this argument in isolation cannot "win". It's the 
sum of arguments that matters.

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