Subject: Re: [linux-audio-dev] lowish-latency patch and toolchain
From: Gregory Maxwell (greg_AT_linuxpower.cx)
Date: Mon Jul 10 2000 - 17:20:51 EEST
[Removed CC from Linux kernel because it's a dead horse and now off topic]
On Mon, 10 Jul 2000, Juhana Sadeharju wrote:
[snip]
> I think 4 ms could be better. If we don't get any agreement we really
> should go for the old 2 ms lowlatency patch and forget any new compromized
> kludge.
>
> It would be nice if Linus would allow keeping this kludge patch as
> compilation option in Linux source tree, so that it comes with every
> Linux distribution. That would be __a real compromize__!
No, it's a __real kludge__ the ingo patch makes the kernel much harder to
maintain because it sprinkles potentially deadlock causing reschedules all
over the code.
It doesn't matter if it's a option because either:
1) The kernel developers will take it into account when making changes,
and it will add hours of extra work avoiding deadlocks.
or
2) They will completely ignore it, making your option not work. (though it
will probably compile and boot, but have random deadlocks)
(1) is unacceptable as Linus and many other developers have stated. They
will not put in the effort to maintain such a kludge.
(2) buys you *NOTHING* over having an externally maintained patch, and is
worse because it will burden core developers will bug reports on code they
have no intrest in maintaining.
You only have FOUR OPTIONS:
1) Do what Linus will accept: I.e. rechedules in VERY limited and
obviously correct places with documentation on why it: Is provable
safe; Will never worsen performance or maintainability; actually a latency
concern; and can not be improved by architectual or algorymthic
changes. Along with good arch and algo improvements.
2) Maintain you own external patch that sprinkles reschedules all over the
place. Deal with avoiding deadlocks and updates, and getting users to
apply the patch. Kernel developers will IGNORE bugreports from thses
users.
3) Fork Linux and do your own thing.
4) Find another OS that fits your needs.
If you are not willing to (3) then you should consider why Linux is only
willing to do (1).
The fact is that Ingo's patch is a maintaince nightmare as Ingo said
himself. The correct solution is to reduce algorymthic complexity,
rearchitect code to avoid latency, make UP preemptiable using the existing
SMP locks, and only add additional reschedules as a absolute last resort.
You will probably be able to get Linux down to 2-3ms latency using this
method, and it will have little negitive impact on maintainablity,
anything beyond that you must move to RTlinux.
This archive was generated by hypermail 2b28 : Mon Jul 10 2000 - 18:43:43 EEST