Messages in this thread |  | | From | Dieter Nützel <> | Subject | Re: 2.4.10-ac10-preempt lmbench output. | Date | Wed, 10 Oct 2001 06:42:37 +0200 |
| |
Am Mittwoch, 10. Oktober 2001 06:23 schrieb Andrea Arcangeli: > On Wed, Oct 10, 2001 at 05:57:46AM +0200, Dieter Nützel wrote:
[...] > > I get the dropouts (2~3 sec) after dbench 32 is running for 9~10 seconds.
It is mostly only _ONE_ dropout like above.
> > I've tried with RT artds and nice -20 mpg123. > > > > Kernel: 2.4.11-pre6 + 00_vm-1 + preempt > > > > Only solution: > > I have to copy the test MPG3 file into /dev/shm. > > If copying the mp3 data into /dev/shm fixes the problem it could be also > an I/O overload.
The above plus nice -20 mpg123 *.mp3 I've forgotten to clearify this, sorry.
Should I try 2.4.11 + 00_vm-1 or 2.4.11aa1, again?
> So if this is just an I/O overload (possible too) some possible fixes > could be: > > 1) buy faster disk
:-)
But I've checked it with two SCSI disks. IBM DDYS U160 10k for dbench 32 and IBM DDRS UW 7.2k for the mp3s
=> the hiccup
> 2) try with elvtune -r 1 -w 2 /dev/hd[abcd] /dev/sd[abcd] that will try > to decrease the global I/O disk bandwith of the system, but it will > increase fairness
OK, after I had some sleep...
> > CPU (1 GHz Athlon II) is ~75% idle during the hiccup. > > Of course I can imagine. This is totally unrelated to scheduler > latencies, it's either vm write throttling or I/O congestion so you > don't have enough bandwith to read the file or both.
It is only _ONE_ time during the whole dbench 32 run.
> > The dbench processes are mostly in wait_page/wait_cache if I remember > > right. So I think that you are right it is a file IO wait (latency) > > problem. > > Yes. > > > Please hurry up with your read/write copy-user paths lowlatency patches > > ;-) > > In the meantime you can use the preemption points in the copy-user, they > can add a bit more of overhead but nothing interesting, I believe it's > more a cleanup than an improvement to move the reschedule points in > read/write as suggested by Andrew. > > BTW, this is the relevant patch: > > ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.4/2.4.11 >aa1/00_copy-user-lat-5
GREAT.
> You're probably more interested in the possible heuristic that I've in > mind to avoid xmms to wait I/O completion for the work submitted by > dbench. Of course assuming the vm write throttling was a relevant cause > of the dropouts, and that the dropouts weren't just due an I/O > congestion (too low disk bendwith).
> BTW, to find out if the reason of the dropouts where the vm write > throttling or the too low disk bandwith you can run ps l <pid_of_xmms>,
What do you mean here? I can't find a meaningfully ps option.
> if it says wait_on_buffer all the time it's the vm write throttling, if > it says always something else it's the too low disk bandwith, I suspect > as said above that you'll see both things because it is probably a mixed > effect. If it's not vm write throttling only a faster disk or elvtune > tweaking can help you, there's no renice-IO -n -20 that allows to > prioritize the I/O bandwith to a certain application.
Thanks, Dieter - 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/
|  |