as Roger Larrson suspected, there are some parts in the kernel
which have a too long execution path:
On his PPro with 512MB RAM, d_lookup takes up to 80ms to execute !
(I put Roger's latency profiling patch on my page)
I tested this on my PII400 (UP box) + 256MB RAM:
The test-kernel was 2.2.10 + a buffer.c patch (from Andrea) + uaccess.h
(from Mingo) patch, which insert additional schedule() calls.
I made 3 tests, booting with mem=64m , mem=128m and mem=256m
the audio buffer was 4.35ms ( 3x256 bytes)
the results are very interesting: (look at the diagrams !)
mem=64m :
/proc stress 3.5ms latency 0 overruns (this is VERY good !)
disk write: 12.5ms latency 18 overruns
disk copy: 11.1ms latency 14 overruns
disk read: 6.3ms latency 16 overruns (quite nice :-) )
http://www.gardena.net/benno/linux/audio/2.2.10+patch+64mb/3x256.html
mem=128m :
/proc stress 5.4ms latency 102 overruns
disk write: 14.5ms latency 20 overruns
disk copy: 11.4ms latency 43 overruns
disk read: 10.5ms latency 7 overruns
http://www.gardena.net/benno/linux/audio/2.2.10+patch+128mb/3x256.html
mem=256m :
/proc stress 9.2ms latency 101 overruns
disk write: 48.7ms latency 13 overruns
disk copy: 31.6ms latency 24 overruns
disk read: 11.9ms latency 4 overruns
http://www.gardena.net/benno/linux/audio/2.2.10+patch+256mb/3x256.html
IMHO having less memory , leads to less mem for disk buffering,
and less pages to process, so the kernel routines take less time
go through lists, inodes etc.
I hope that the delay of the release of Mingo's patch is related to
the fact that he tries to shorten these paths, which is not always a trivial
task.
Mingo, can you confirm this ?
comments ?
ciao,
Benno.
-- Benno Senoner E-Mail: sbenno@gardena.net Linux scheduling latency benchmarks http://www.gardena.net/benno/linux/audio
- 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/