* Andrew Morton <[email protected]> wrote:
> Sven Dietrich <[email protected]> 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
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?)
but this is getting offtrack. -RT does have direct benefits for pro
audio (and of course embedded systems) users, maybe also interactivity
benefits for slower/older systems, but i'm not trying to argue that it's
necessary for the generic desktop. (especially considering the kernel
overhead)
but there exist other indirect benefits: what is a scheduling latency
critical path on CONFIG_PREEMPT, is still a (secondary) critical path on
PREEMPT_RT too, which embedded people will try to improve. The same is
true for voluntary-preempt: if you break a latency path on
CONFIG_PREEMPT, you implicitly improve PREEMPT_VOLUNTARY too. So there
are fundamental cross-effects between the preemption models, and by
cowardly luring those embedded developers into using the stock Linux
kernel instead of hacking on their own isolated patches/trees (or OSs)
we indirectly improve latencies of the desktop preemption model too.
Please dont underestimate the amount of development that goes on in the
embedded world, the more of them use Linux, the better for all Linux
users.
it's also a perception thing: if Linux _can_ offer sub-100 usec
latencies, embedded developers are more likely to pick it for their
project - even if the hardware does not need so good latencies. Embedded
developers (and OS vendors) will be more likely to standardize on Linux
exclusively, if they know that whatever future customer comes around,
Linux will be able to perform.
it's pretty much the same story as with scalability: only a few people
needs Linux to scale to 500 CPUs (in fact only a small precentage needs
anything above 4 CPUs), but the perception advantage gives 2-CPU people
the warm fuzzy feeling that if Linux works fine on 500 CPUs then it must
be more than adequate on 2 CPUs. Is anyone going to argue that Linux
does not need to scale above 4 CPUs just because the number of users in
that space is less than 1%?
[ of course this is all just talk, but people seem to have a desire to
talk about it :-) ]
Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
