try it with vanilla 2.4.17-rc1. I just did and i'm getting no
stuttering at all. nice -n 20 dbench 32. Worked quite nicely. Of
course i'm using an ext3 fs which is more important than your cpu speed
or ram. This kind of discussion has been talked about and argued over
many times in the past here already. Too many factors go into this and
in the end, dbench is _Meant_ to preempt everything else. if you want
a real test find a real program you really use and use it.
> > > 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/
>
-
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/