Hi again,
Made a mistake in this report.
I was actually running against the older WDC AC22100H.
But I have now retested with the newer WDC AC33200L and
the result is the same. I get worse latencies with the
AC33200L (latencies from audio interrupt with a SCHED_FIFO
process that itself does no disk IO)
The pattern looks like the new WD disk has fewer but longer
spikes than the Seagate.
[Note: there are probably lots of even better disks than the
Seagate - bought it since it is big and cheap (quiet too)]
/RogerL
Roger Larsson wrote:
>
> Hi,
>
> I made a HW patch.
> Added a Seagate U10 ST320423A (20,4 GB)
>
> <6>Uniform Multi-Platform E-IDE driver Revision: 6.31
> <4>ide: Assuming 30MHz system bus speed for PIO modes
> <4>PIIX3: IDE controller on PCI bus 00 dev 39
> <4>PIIX3: chipset revision 0
> <4>PIIX3: not 100% native mode: will probe irqs later
> <4> ide0: BM-DMA at 0xffa0-0xffa7, BIOS settings: hda:pio, hdb:pio
> <4> ide1: BM-DMA at 0xffa8-0xffaf, BIOS settings: hdc:pio, hdd:pio
> <4>hda: WDC AC33200L, ATA DISK drive
> <4>hdb: ST320423A, ATA DISK drive
> <4>hdc: WDC AC22100H, ATA DISK drive
> <4>ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
> <4>ide1 at 0x170-0x177,0x376 on irq 15
> <6>hda: 6346368 sectors (3249 MB) w/256KiB Cache, CHS=787/128/63, (U)DMA
> <6>hdb: 40011300 sectors (20486 MB) w/512KiB Cache, CHS=2490/255/63,
> (U)DMA
> <6>hdc: 4124736 sectors (2112 MB) w/128KiB Cache, CHS=4092/16/63, DMA
>
> And did my streaming test against it instead of the WDCAC33200L.
>
> Performance doubled as it should, sustained throuput should be a lot
> better for the new Seagate.
>
> But more interesting is that latencies went way down - why ?
> (running with Andrews low latency patch)
>
> # first run only DMA, readahead 8
>
> Jul 15 01:19:51 dox kernel: Latency 5ms PID 2 % kswapd
> Jul 15 01:26:24 dox kernel: Latency 7ms PID 0 % swapper
>
> # second run, multicount 8, 32bit, unmaskirq, DMA, readahead 8
>
> Jul 15 01:33:47 dox kernel: Latency 8ms PID 2 % kswapd
> Jul 15 01:33:47 dox kernel: Trace: [shrink_mmap+66/532]
> Jul 15 01:34:04 dox kernel: Latency 5ms PID 328 % bash
> Jul 15 01:34:04 dox kernel: Trace: [__mark_buffer_dirty+54/56]
> Jul 15 01:34:09 dox kernel: Latency 11ms PID 2 % kswapd
> Jul 15 01:34:09 dox kernel: Trace: [shrink_mmap+66/532]
> Jul 15 01:34:36 dox kernel: Latency 6ms PID 2 % kswapd
> Jul 15 01:34:37 dox kernel: Trace: [shrink_mmap+66/532]
> Jul 15 01:35:54 dox kernel: Latency 5ms PID 2 % kswapd
> Jul 15 01:35:55 dox kernel: Trace: [shrink_mmap+66/532]
> Jul 15 01:36:02 dox kernel: Latency 19ms PID 0 % swapper
> Jul 15 01:43:46 dox kernel: Latency 7ms PID 0 % swapper
>
> That is all above 5 ms two runs, compare that to the old one.
> (a run = 3 * write 150 MB, 3 * copy 150 MB,
> 3 * read 300 MB, 3 * diff 150 MB)
>
> kernel folks:
> * Why do I get better latencies?
> * Why does latencies get worse when enabling good options?
>
> /RogerL
>
> --
> Home page:
> http://www.norran.net/nra02596/
>
> -
> 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/
-- Home page: http://www.norran.net/nra02596/- 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/
This archive was generated by hypermail 2b29 : Sat Jul 15 2000 - 15:45:47 EDT