Mark Hahn wrote:
> > I can't do such a test because my swap is on the same drive as the one i
> > took those tests. But, I ran it at 384MB (128MB of ram) on my other drive
> > and this is what it gave me.
>
> same make/model of disk?
>
> > -------Sequential Output-------- ---Sequential Input--
> > --Random--
> > -Per Char- --Block--- -Rewrite-- -Per Char- --Block---
> > --Seeks---
> > Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec
> > %CPU
> > 1* 384 4496 98.4 14440 18.7 7997 20.5 4656 95.6 13092 22.6 98.7
> > 2.8
>
> those are sane numbers. for instance, 98.7 seeks/second are close to
> correct.
>
> > OK, now before you go saying "i told you so" let me just say that this
> > reading is almost no worse and in some places better than the 100MB test i
> > did before doing the patch. Also, this was done on the 20GB ext2fs
> > partition / drive which is slave to the one i originally did the tests on.
> > I'd have to reboot to test without the patch but i'm not doing that unless
> > i crash. I did the test again at the default size (like i did the first
> > two tests) on this same partition.. to show you just how little increasing
> > the size matters
> > -------Sequential Output-------- ---Sequential Input--
> > --Random--
> > -Per Char- --Block--- -Rewrite-- -Per Char- --Block---
> > --Seeks---
> > Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec
> > %CPU
> > 1* 100 4530 99.2 15479 19.3 9769 24.6 4558 94.0 12853 21.8 772.5
> > 17.8
> >
> > As you can see, there are only minor differences. The VM patch kicks ass
> > ..hands down.
>
> the patch is fine. but if you think these scores are similar,
> I guess you're looking at the per-char columns. they reflect
> mainly your CPU and glibc performance, not the disk or VM.
>
> whether a too-small file makes a big difference in block IO depends
> on whether your ram and CPU are fast enough. for instance, on a
> dual celeron/550:
> -------Sequential Output-------- ---Sequential Input-- --Random--
> -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks---
> MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU
> 100 17474 74.6 20317 19.2 14104 13.8 35068 99.3 189629 98.1 50000.0 212.5
>
> obviously, some of those scores are silly...
>
> regards, mark hahn.
Both disks are Matrox UDMA66 7200rpm hdd's but one is 10.2GB and the other is
20GB. one is done on a 20GB partition, the other on the 7GB partition. The
tests i did first were on the 7GB ..but that also resides no the drive which has
the swap partition. so using files greater than my ram caused a lot of swap
action so the test would be invalid. You made a point that larger test file size
would make all the difference in your first reply so i showed that on the other
partition (disk without the swap) that both readings are not that far off except
for seeks and in the Sequential Input Block readings it was better with the
larger file size. I cannot test the 7GB partition which gave me those
tremendous readings with the larger filesize because of the swap partition being
on that drive and my lack of other drives to put it. my cpu is a pii 300 with
128mb sdram at 66mhz on a 440lx mobo. All of the columns were within or little
over 1MB of difference ..that's what i call similar. if anyone is going to gock
over something smaller than 1MB of difference they have other problems besides
IO performance to deal with. As for the patch causing a hit on IO performance
.. i just dont see it, i dont know what hdd setups people are seeing it with,
but i dont think it affects mine at all in any negative way. Under certain
situations anything can be made to look bad and of course bonnie isn't a catch
all factor. Bonnie++ doesn't even catch all, but it's a good test and until
someone can show me a better one ..i'll use that. Some scores i did find
unbelievable in my initial test of the 7GB partition ...but i find that
partition to be faster by far than my 20GB partition (which i think is mostly
due to fs overhead caused by the large ext2 partition). I continue to stand by
my original stand that the patch kicks ass all around because i havn't been
proven otherwise
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Sep 07 2000 - 21:00:15 EST