[Bug 131094] Re: Heavy Disk I/O harms desktop responsiveness

[Hendrik van den Boogaard]

@Thomas, I can try the 'time cat..' line later but I don't think it will
reveal information other than that catting the SATA harddisk is probably
faster, because the drive is generally faster (higher capacity per
platter, more cache).

@KhaaL, I must say that for the last test I used Anticipatory as
queueing mechanism, I found that out jsut before rebooting, but both the
PATA and SATA harddisks were set on Anticipatory, and both had the same
amount of read ahead set, at that time 4096.

Native Command Queueing can be changed by changing the value of
'queue_depth' for a specific drive. You can find it like this:

cd /sys
find |grep queue_depth

Now the system will report a file like 
./devices/pci0000:00/0000:00:0e.0/host2/target2:0:0/2:0:0:0/queue_depth

I will post my findings in

If you look inside that file you can see the value it is on (just 'cat'
it) and you can change the value by something like

echo 1 >
./devices/pci0000:00/0000:00:0e.0/host2/target2:0:0/2:0:0:0/queue_depth

If it is already 1, your drive might not support NCQ.

I will post my findings in the other thread later. What I can also try
is to make an exact copy of the contents of the SATA drive to an other
SATA or PATA drive laying around and see if the sluggishness is
different.

@Milan: you might think that the system on SATA is more sluggish than on
PATA as it contains the system files, but even just alt-tabbing through
windows is sluggish. If I do this with no I/O load on the drive this
tabbing through programs does not interact with the disk as all programs
are in memory and swap is turned off. When I start the load on the PATA
drive the system remains responsive and windows just appear when I alt-
tab, perhaps with a short delay, but that is ok. When I start the load
on the SATA drive however, the alt-tab may take seconds to complete
before the selected window appears. That's strange isn't it? To make
sure I want to do the test mentioned above by 'dd-ing' the full SATA
drive to the PATA or some other PATA/SATA drive and do the same test on
the drive the system boots from.

@Jamie: NCQ might be horrible on the drive, afaik it is one of the first
500 GB 7200.10 drive from Seagate. I can try to update its firmware but
if that removes the problem I cannot help out anymore ;). On my 7200.11
1 TB drives (also one of the first 1 TBs on the market) I also disabled
NCQ because I found some thread that it might kill the contents of the
file system. If you want I can lookup where I found that. I had a
problem with my RAID 5 array in a server with these 1 TB disks and
contacted the libata maintainers but I had to restore the bad sector
before my array was destroyed by not having a spare disk, so after
fixing the bad sector I could not reproduce the problem anymore. In the
meantime I switched that server to an older kernel, probably a stock
kernel from Gutsy or Feisty.

Hendrik: The fact that work on your SATA drive makes the system
sluggish, contrary to the PATA one, is normal since your system files
are on that drive. Schedulers only deal with processes competing for the
same drive access. If the problem is actually with SATA, the only proof
we have is that you only changed your drive to SATA, and nothing else.

I'm now at work so I cannot test, but I must say that I have the exact
same configuration over here except for a 5000+ processor instead of a
5200+. This machine however has a SATA disk and I never experienced any
sluggishness on this machine, so far running Hardy and Intrepid. So the
sluggishness may even be drive specific?

-- 
Heavy Disk I/O harms desktop responsiveness
https://bugs.launchpad.net/bugs/131094
You received this bug notification because you are a member of Kernel
Bugs, which is subscribed to Linux.