Amen..
Sorry, Helge sure you are right in theory but try dbench 32 (maybe
bonnie/bonnie++) and playing an MP3/Ogg-Vorbis in parallel...
That's my first test on any "new" kernel version.
Even with an 1 GHz Athlon II, 640 MB, U160 DDYS 18 GB, 10k IBM disk (on an
AHA-2940UW) it stutters like mad. I am running all my kernel _with_ Robert
Love's preempt + lock-break patches and it doesn't solve the problem.
CPU load is (very) low but it do not work like it should.
> > pre-empt the rest of the system" switch for the eide drives? Is there
> > something fundamental/unique going on here that I'm missing?
> dma, udma, etc. is that switch. It lets the cpu do other work (such as
> redrawing X) while the disk is busy. Plain ide is what you don't want.
See above the whole system show some bad hiccup.
> The problem of waiting for other files or swapping while a really big
> write is going on is different. Get more drives, so the big writes go
> to one drive while you get stuff swapped in (or other file access)
> on other drive(s). The kernel is capable of getting fast response
> from one drive while another is completely bogged down with
> enormous writes.
Tried this already. Neither I put my test files (MP3/Ogg-Vorbis) in /dev/shm
or a nother disk it do not change anything.
There must be something in the VFS?
-Dieter
-- Dieter Nützel Graduate Student, Computer Science University of Hamburg @home: Dieter.Nuetzel@hamburg.de - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/