On Fri, 11 Aug 2000, Corin Hartland-Swann wrote:
>
> Mark,
>
> I'm cross-posting this to the kernel and RAID lists again, because there's
> more information about the problem in here. I hope this is acceptable.
>
> On Thu, 10 Aug 2000, Mark Hahn wrote:
> > > Intel 810E Chipset Motherboard (CA810EAL), Pentium III-667, 32M RAM,
> > > Maxtor DiamondMax Plus 40 40.9GB UDMA66 Disk, Model 54098U8
> >
> > a low-memory machine, by today's standards. with one of the fastest
> > disks available. and, for that matter, a pretty fast CPU.
>
> The RAM is deliberately lowered - it normally has 128M. I lowered it so
> that I could benchmark with 256M file size, instead of the 1G or so it
> would take to get decent results.
>
> The idea behind the spec was to use really quite currrent components,
> fast processor and disk to stress the kernel as much as possible and
> reveal bottlenecks.
>
> > > I used tiotest to benchmark, using a file size of 256MB, block size of 4K,
> > > and with 1, 2, 4, 16, 32 threads. The performance starts to get hit as
>
> I forgot to add that I ran each test five times so as to get consistent
> results.
>
> > does larger blocksizes change the picture at all? I'm wondering whether
> > readahead is effecting things (shouldnt, but...)
>
> mke2fs only allows block sizes of 1K, 2K or 4K, so I can't make the
> blocksize any larger...
>
> > > ==> 2.2.16 <==
> > > Dir Size BlkSz Thr# Read (CPU%) Write (CPU%) Seeks (CPU%)
> > > ----- ------ ------- ---- ------------- -------------- --------------
> > > /mnt/ 256 4096 1 27.0948 10.5% 25.9272 22.5% 147.264 0.83%
> > > /mnt/ 256 4096 2 20.5753 8.42% 25.9316 22.7% 143.113 0.56%
> > > /mnt/ 256 4096 4 13.0397 6.09% 25.7723 22.7% 143.619 0.51%
> > > /mnt/ 256 4096 16 9.38573 5.40% 25.6285 23.1% 147.815 0.51%
> > > /mnt/ 256 4096 32 6.96358 5.90% 25.2889 22.9% 151.182 0.57%
> >
> > so when this is running, does "vmstat 1" indicate that the system's
> > swapping? I'm guessing so, that it's trying to scavenge pages from
> > live processes, ineffectually (since they're live), and thrashing.
>
> After going to all the trouble of testing this out, I remembered that I
> had not allocated any swap so that it couldn't influence the results at
> all! d'oh!
>
> > > I also tested 2.4.0-test5, and performance there sucks with one thread,
> > > but doesn't degrade any more quickly than 2.2.15
> > >
> > > ==> 2.4.0-test5 <==
> > >
> > > Dir Size BlkSz Thr# Read (CPU%) Write (CPU%) Seeks (CPU%)
> > > ----- ------ ------- ---- ------------- -------------- --------------
> > > /mnt/ 256 4096 1 8.15398 49.6% 7.64104 71.2% 125.675 5.90%
> > > /mnt/ 256 4096 2 8.01528 56.1% 7.63085 69.8% 123.076 5.59%
> > > /mnt/ 256 4096 4 7.79720 61.6% 7.62060 68.1% 125.437 5.75%
> > > /mnt/ 256 4096 16 7.64617 65.2% 7.60466 62.5% 129.431 5.83%
> > > /mnt/ 256 4096 32 7.60580 67.6% 7.58702 51.7% 132.791 5.95%
> >
> > wow, that's horrible performance. I have some of these disks,
> > and have never seen anything that bad. have you verified that
> > the ide controller is being recognized properly, that it's
> > using a decent udma33 or udma6 mode, etc?
>
> I think I've located the problem... (with kernel 2.4, anyway) - it is
> refusing to use DMA.
>
> When I try hdparm -m -c -d1 -a, I get the following output:
>
> /dev/hdc:
> setting using_dma to 1 (on)
> HDIO_SET_DMA failed: Operation not permitted
> multcount = 16 (on)
> I/O support = 1 (32-bit)
> using_dma = 0 (off)
> readahead = 8 (on)
>
> The other values are the same as the ones I'm using under the other
> kernels. My dmesg output looks like this:
>
> ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
> PIIX4: IDE controller on PCI bus 00 dev f9
> PIIX4: chipset revision 2
> PIIX4: not 100% native mode: will probe irqs later
> hda: IBM-DJNA-371350, ATA DISK drive
> hdb: Maxtor 54098U8, ATA DISK drive
> hdc: Maxtor 54098U8, ATA DISK drive
> ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
> ide1 at 0x170-0x177,0x376 on irq 15
> hda: 26520480 sectors (13578 MB) w/1966KiB Cache, CHS=1650/255/63
> hdb: 80041248 sectors (40981 MB) w/2048KiB Cache, CHS=4982/255/63
> hdc: 80041248 sectors (40981 MB) w/2048KiB Cache, CHS=79406/16/63
> Partition check:
> hda: hda1 hda2 hda3
> hdb: hdb1
> hdc: [PTBL] [4982/255/63] hdc1
>
> Can anyone explain to me what the [PTBL] bit means? I've been wondering
> this for about 4 years now, and still don't know :)
>
> Anybody have any suggestions about how to get DMA working? Is it a problem
> with the IDE controller?
>
> > > I haven't tried any of this with SCSI disks, so the problem may well lie
> > > in VFS or the VM subsystem (I know there are problems there as well). I
> > > don't know anything about those, so I guess I should just leave it to the
> > > professionals now :)
> >
> > hmm, I just booted my dev machine with mem=32m, rather than it's normal
> > 128M. it gave the same bonnie results as with 128m.
>
> The amount of RAM shouldn't affect disk results. If it does, then the test
> file size you are using with the benchmarking tool isn't big enough. So,
> basically, this is the right result.
>
> Thanks,
>
> Corin
>
> /------------------------+-------------------------------------\
> | Corin Hartland-Swann | Direct: +44 (0) 20 7544 4676 |
> | Commerce Internet Ltd | Mobile: +44 (0) 79 5854 0027 |
> | 22 Cavendish Buildings | Tel: +44 (0) 20 7491 2000 |
> | Gilbert Street | Fax: +44 (0) 20 7491 2010 |
> | Mayfair | Web: http://www.commerce.uk.net/ |
> | London W1K 5HJ | E-Mail: cdhs@commerce.uk.net |
> \------------------------+-------------------------------------/
>
>
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.rutgers.edu
> Please read the FAQ at http://www.tux.org/lkml/
>
Andre Hedrick
The Linux ATA/IDE guy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/