Juhana Sadeharju wrote:
>
> >From: Andrew Morton <andrewm@uow.edu.au>
> >
> >doing silly things, the scheduling latency is reliably 4 milliseconds on
> >a 500MHz machine. Very occasionally reaches 7 millisecs. It has been
>
> Lets talk about 7 ms latency only -- 4 ms is useless information in audio
> software which has to be 101% reliable. That is poor compared to earlier
> results 2.5 ms. Or can audio input-output latency between A/D & D/A be
> somehow less than 7 ms?
If I recall correctly, the 7msecs was due to starting the X server, and
to switching consoles.
I'll do some more tests, but the point I'm trying to get across is this:
It's no good testing it with my workload! It has to be tested with
yours. So please, get down and get testing. There isn't a lot of time.
> >Here's the current DDT list:
> >
> >- Don't delete huge files (100 megs). There's a hungry
> > loop in zap_page_range which has no clear-and-easy fix.
> > There _was_ a fix in Ingo's patch, but additional 2.4
> > threading has made that unviable.
>
> That is quite important to get fixed. Only perfectionist such as me
> would reuse files without deleting them in an audio software. The files
> can be very large and very temporary.
This problem (deleting large files) is quite illustrative.
In kernel 2.2, this code path was a globally locked monolith, and Ingo's
conditional_reschedule() fitted in quite nicely.
In kernel 2.4, much finer SMP granularity has been introduced, so these
code paths are now bristling with spinlocks. Consequently the 2.2
reschedule would deadlock in 2.4. One approach would be to open the
locks, reschedule and close them again at select points. That's
downright scary, and definitely on the wrong side of the dividing line
which (I hope) we have agreed upon here.
-
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/
This archive was generated by hypermail 2b29 : Sat Jul 15 2000 - 21:00:09 EST