Messages in this thread |  | | Date | Sun, 03 Sep 2000 12:33:21 -0400 | From | safemode <> |
| |
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/
|  |