LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
* Writing to disks takes system to it's knees when using libata with sil3112
@ 2004-05-20 19:40 Pauli Borodulin
  0 siblings, 0 replies; only message in thread
From: Pauli Borodulin @ 2004-05-20 19:40 UTC (permalink / raw)
  To: linux-kernel

Hello,

I recently upgraded my kernel from 2.4.25 to 2.6.6 and started using 
libata. I used siimage.c with 2.4 and it worked fine enough with this 
patch applied: 
http://www.kernel.org/pub/linux/kernel/people/bart/2.6.0-test11-bart1/broken-out/ide-siimage-seagate.patch

Now with 2.6.6 and libata, all things don't seem to work that well. I 
use couple of Maxtor's 120GB SATA-disks (6Y120M0) in software raid 
configuration (mirroring) with Silicon Image's SIL3112. Hdparm seems to 
indicate correct performance for the disks, but writing to the disks is 
slow and makes my system sluggerish. Good example is running bonnie++ 
(bonnie++ -u nobody -d /archive/tmp -s 1024 -n 0) to test the speed of 
my raid. Bonnie++ writing its test file (putc part) is really slow, 
something like 1MB/s. If I press ctrl-c, it takes a short while to end, 
and while that ps reports bonnie++'s status as "D" (uninterruptible 
sleep). Also kjournald seems to be as "D". Intelligently writing part 
works faster (higher MB/s), but system remains quite slow thru' the 
whole test. I also tried copying files to my raid with cp and it's the 
same 1MB/s.

I noticed the bad performance first after booting my system to 2.6.6: my 
raid mirror was in unsync and md started recovering it in the background 
-- highest speed I saw while watching /proc/mdstat was about 1MB/s and I 
had hard time trying to do anything. With 120GB disks, I had no other 
choice than cancel it. Reading from the disks seems to work better, cat 
really-big-file > /dev/null doesn't disturb other activity and works as 
quickly as it should.

I did try changing the disks behind a HPT374 with serial ata bridges and 
I reached about 17MB/s speed without any interference. I assume there's 
something wrong with libata's 3112/3114-support. Any ideas how to fix 
this would be good.

Here's libata's output from dmesg:

libata version 1.02 loaded.
sata_sil version 0.54
ata1: SATA max UDMA/100 cmd 0xE0826080 ctl 0xE082608A bmdma 0xE0826000 
irq 18
ata2: SATA max UDMA/100 cmd 0xE08260C0 ctl 0xE08260CA bmdma 0xE0826008 
irq 18
ata1: dev 0 cfg 49:2f00 82:7c6b 83:7b09 84:4003 85:7c69 86:3a01 87:4003 
88:207f
ata1: dev 0 ATA, max UDMA/133, 240121728 sectors
ata1: dev 0 configured for UDMA/100
scsi0 : sata_sil
ata2: dev 0 cfg 49:2f00 82:7c6b 83:7b09 84:4003 85:7c69 86:3a01 87:4003 
88:207f
ata2: dev 0 ATA, max UDMA/133, 240121728 sectors
ata2: dev 0 configured for UDMA/100
scsi1 : sata_sil
   Vendor: ATA       Model: Maxtor 6Y120M0    Rev: 1.02
   Type:   Direct-Access                      ANSI SCSI revision: 05
   Vendor: ATA       Model: Maxtor 6Y120M0    Rev: 1.02
   Type:   Direct-Access                      ANSI SCSI revision: 05
SCSI device sda: 240121728 512-byte hdwr sectors (122942 MB)
SCSI device sda: drive cache: write through
  /dev/scsi/host0/bus0/target0/lun0: p1 p2
Attached scsi disk sda at scsi0, channel 0, id 0, lun 0
SCSI device sdb: 240121728 512-byte hdwr sectors (122942 MB)
SCSI device sdb: drive cache: write through
  /dev/scsi/host1/bus0/target0/lun0: p1 p2


Regards,
-- 
Pauli Borodulin

^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2004-05-20 19:40 UTC | newest]

Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-05-20 19:40 Writing to disks takes system to it's knees when using libata with sil3112 Pauli Borodulin

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).