File './Bonnie.2276', size: 1073741824, volumes: 1
Writing with putc()... done: 72692 kB/s 83.7 %CPU
Rewriting... done: 25355 kB/s 12.0 %CPU
Writing intelligently...done: 103022 kB/s 40.5 %CPU
Reading with getc()... done: 37188 kB/s 67.5 %CPU
Reading intelligently...done: 40809 kB/s 11.4 %CPU
Seeker 2...Seeker 1...Seeker 3...start 'em...done...done...done...
---Sequential Output (nosync)--- ---Sequential Input-- --Rnd Seek-
-Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --04k (03)-
Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU
1*1024 72692 83.7 103022 40.5 25355 12.0 37188 67.5 40809 11.4 382.1 2.4
Maybe this is the kind of performance you want out your ATA subsystem.
Maybe if I could get a patch in to the kernels we could all have stable
and fast IO.
Regards,
Andre Hedrick
CEO/President, LAD Storage Consulting Group
Linux ATA Development
Linux Disk Certification Project
On 17 Dec 2001, jlm wrote:
> I have been witnessing what I believe to be poor performance from my
> computer ever since I have moved into the 2.4.x kernel versions. Combing
> through the unofficial archives of this mailing list reveals some others
> having similar problems, but I haven't seen any real resolution, or
> maybe their problems are completely different than mine.
>
> The problem simply is that whenever the computer does a big disk write,
> everything else is put on hold. Maybe this isn't a problem, but just the
> way it was written. I have tested this on a 2.2.x kernel and it also
> does it, but to a much lesser extent, to the point that I noticed the
> performance loss in the upgrade to a 2.4.x kernel and decided to
> investigate further.
>
> But also, I do not have any performance problems with disk reads.
> Programs can be loading up all they want and I am able to use my
> computer for other things during that time. It just seems to me (maybe
> I'm wrong) that the computer should be able to send small bits of data
> to the disk for writing during the off cycles and not affect the rest of
> the system (which is what I imagine it is doing for reads).
>
> To test, I've got a 142Meg file. I copy it around, makeing sure to copy
> from one disk to another. Of course the copy goes fine, because it does
> a cache (as I've been reading here), but eventually it needs to write
> out to disk (or when I do a sync) and here is where the computer hangs
> for a bit. If an mp3 is playing, it halts for 5 seconds at a time, mouse
> movement on the screen is VERY jerky, Gkrellm will stop updating for
> seconds and even just in console I can't type in stuff for a bit.
>
> I've been using hdparm to try and tweak hard disk access, but I'm not so
> sure this is the problem, and it's making me more confused about the
> entire situation. hdparm doesn't allow me to set using_dma, which it
> seems ought to be a necessity for getting a decent speed out of your
> hard drives (not that speed is the problem here), but despite that I
> still get a 51MB/s cache read speed in testing. Confusing, is the hard
> drive using (u)dma or not? Also, unmaskirq masks things a bit slower.
>
> So, the questions: Is there a way for me to stop this, some configure
> option? Is it a bug/performance issue that needs to be addressed in the
> kernel? Should I just go back to the 2.2.x kernel series and shutup
> already?
>
> I'm running 3 hard drives (30G Maxtor, 20G Seagate, and 2.1G Quantum
> Fireball) on an AMD k6-2 3dnow with a Gigabyte GA-5AX MOBO and the ALI
> Aladin V chipset.
>
> Thanks for your time and let me know if you need any more info/ output
> from dmesg or something.
>
> --
> MACINTOSH = Machine Always Crashes If Not The Operating System Hangs
> "Life would be so much easier if we could just look at the source code."
> - Dave Olson
>
> -
> 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/
This archive was generated by hypermail 2b29 : Sun Dec 23 2001 - 21:00:17 EST