> I haven't managed to actually do this. The fastest machine I tried was
> a P133 with 4-gig Micropolis fast-wide-SCSI on an AHA2940 with 128 megs
> of RAM in single-user mode. It averaged ten buffer overruns per hour
> if I made the machine think it had 16 megs of RAM, and the more RAM I tried
> to use (using 'mem=' at the LILO prompt), the worse the performance got.
> I've tried this with kernels in the 1.3.30's, 1.3.50's, 1.3.80's, and 2.0
> series.
does this patch help?:
------------------------------------------------------------------------>
--- linux/mm/filemap.c.original Tue Jan 28 21:43:40 1997
+++ linux/mm/filemap.c Tue Jan 28 21:44:00 1997
@@ -677,6 +677,8 @@
pos += nr;
read += nr;
count -= nr;
+ if (need_resched)
+ schedule();
if (count)
continue;
break;
<-----------------------------------------------------------------------
[ i've done this from memory, havent even compiled it ... it's for 2.1.22,
but should go into any kernel easily, just identify the place to patch
and do it by hand ]
The page cache file read function is the biggest RT latency source in
Linux, by far.
alternatively, you might want to hack the recording code to use a RT
scheduling policy, you just have to do this somewhere at the beginning of
main():
------------------------------------------------->
#include <sched.h>
#include <stdlib.h>
#include <stdio.h>
#include <sys/mman.h>
#include <unistd.h>
int main( void )
{
struct sched_param schp;
schp.sched_priority = 98;
sched_setscheduler( 0, SCHED_FIFO, &schp);
mlockall(0);
[... unchanged original code ...]
<-------------------------------------------------
the above code has to run as root. [and you need a recent libc]
be careful, if the above code hangs, it hangs all other processes (because
it's the highest priority process and nothing is allowed to preempt it,
not even bdflush or kswapd).
and to get RT priorities working properly with async events like 'sound io
finished' you need this small kernel/sched.c patch too: [again untested
and against 2.1.22]:
--------------------------------------------------------------->
--- linux/kernel/sched.c.original Fri Jan 24 17:48:09 1997
+++ linux/kernel/sched.c Tue Jan 28 21:54:53 1997
@@ -115,7 +115,7 @@
return;
}
#endif
- if (p->counter > current->counter + 3)
+ if ((p->counter > current->counter + 3) || p->policy)
need_resched = 1;
nr_running++;
(p->prev_run = init_task.prev_run)->next_run = p;
<---------------------------------------------------------------
additionally, i dont know wether sound drivers use 'slow irq handlers' (i
think they do), look into your card's driver. (if you see the SA_INTERRUPT
flag, it's bad). Only slow irq handlers can preempt other running
processes, 'fast irq handlers' driven event will reach the process only
in the next timer tick. [which is ok for interactive work and most other
things, but bad for RT]
If you are still getting overruns [you shouldnt], mail me, got a profiler
that measures such latencies in the kernel. And tell if they go away too
:)
-- mingo