This doesn't sound too sexy... But it seems pretty obvious to me that it can't
be solved by speeding things up. This is why RTKs are preemptive, or keep that
kind of operations in user space...
> It not an easy task to keep latencies down.
Are you serious? ;-))
> Maybe the checking generates some cache misses and decreases performance,
> especially when copying many small blocks ?
Hmmm... If that's what's happening, the "fix" must be doing something it
shouldn't. Why would checking the value of an argument that will be used anyhow
cause extra cache misses to the degree that we get performance problems?
> > > I think most of us want to have these "low-latency" features in the upcoming
> > > 2.4 kernel since it will make Linux a very good _MULTIMEDIA_OS_.
> >
> > Everybody wants low-latency. But Linus looked at the patches and said
> > "If *that* helps then something is wrong. Those functions shouldn't
> > take so much time!"
> > He then refused to accept patches that "paper over" a bug. Instead he
> > wanted the bug fixed (i.e. make the functions in question take less
> > time - they way they should.)
Linus is right, of course. But if the problem really is memory block
operations...?
> Agreed, but the question is: is some kernel hacker motivated to do
> implement this before 2.4 ?
>From what I can remember of those posts, the functions that needs fixing aren't
exactly trivial. Bug fixes or new features?
> > That would give the same low latency without hurting disk performance under
> > load.
>
> I'm not 100%sure about this ..
> Nothing comes at zero cost..
No... But IMO, as long as the cost when using the system as a normal server is
next to none, and reasonably low when torturing the machine with low latency
real time stuff, we're on the right track. As long as the code isn't ruined,
that is.
Well, there is RTLinux, but my experience so far is that, despite the
spectacular performance in the RT area, it's not too popular in the multimedia
hacking community. Some just won't realize that hard real time programming is
*different* from normal application programming, and others can't accept the
most serious problem of RTL; the lack of protected memory. (No wonder. Back
where Windoze/DirectX is...) I'll play it later on, but it's NOT a trivial
hack as far as I can see now.
So where are we going? Have another look at RTLinux scheduling into user space
(or some other way of getting protected memory), or keep trying to get below
this 3 ms jitter level with standard kernels? Or make it a compile time choice?
//David
PS. Why do some mail clients seem to think Majordomo would be interested in
these posts? Are the machines planning a revenge or something?
·A·U·D·I·A·L·I·T·Y· P r o f e s s i o n a l L i n u x A u d i o
- - ------------------------------------------------------------- - -
·Rock Solid David Olofson:
·Low Latency www.angelfire.com/or/audiality ·Audio Hacker
·Plug-Ins audiality@swipnet.se ·Linux Advocate
·Open Source ·Singer/Composer
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/