Re: Where is the performance bottleneck?

[Jens Axboe <axboe@suse.de>]

On Wed, Aug 31 2005, Vojtech Pavlik wrote:
> On Tue, Aug 30, 2005 at 08:06:21PM +0000, Holger Kiehl wrote:
> > >>How does one determine the PCI-X bus speed?
> > >
> > >Usually only the card (in your case the Symbios SCSI controller) can
> > >tell. If it does, it'll be most likely in 'dmesg'.
> > >
> > There is nothing in dmesg:
> > 
> >    Fusion MPT base driver 3.01.20
> >    Copyright (c) 1999-2004 LSI Logic Corporation
> >    ACPI: PCI Interrupt 0000:02:04.0[A] -> GSI 24 (level, low) -> IRQ 217
> >    mptbase: Initiating ioc0 bringup
> >    ioc0: 53C1030: Capabilities={Initiator,Target}
> >    ACPI: PCI Interrupt 0000:02:04.1[B] -> GSI 25 (level, low) -> IRQ 225
> >    mptbase: Initiating ioc1 bringup
> >    ioc1: 53C1030: Capabilities={Initiator,Target}
> >    Fusion MPT SCSI Host driver 3.01.20
> > 
> > >To find where the bottleneck is, I'd suggest trying without the
> > >filesystem at all, and just filling a large part of the block device
> > >using the 'dd' command.
> > >
> > >Also, trying without the RAID, and just running 4 (and 8) concurrent
> > >dd's to the separate drives could show whether it's the RAID that's
> > >slowing things down.
> > >
> > Ok, I did run the following dd command in different combinations:
> > 
> >    dd if=/dev/zero of=/dev/sd?1 bs=4k count=5000000
> 
> I think a bs of 4k is way too small and will cause huge CPU overhead.
> Can you try with something like 4M? Also, you can use /dev/full to avoid
> the pre-zeroing.

That was my initial thought as well, but since he's writing the io side
should look correct. I doubt 8 dd's writing 4k chunks will gobble that
much CPU as to make this much difference.

Holger, we need vmstat 1 info while the dd's are running. A simple
profile would be nice as well, boot with profile=2 and do a readprofile
-r; run tests; readprofile > foo and send the first 50 lines of foo to
this list.

-- 
Jens Axboe

-
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/