linux-kernel - Re: SCSI Controler SCRU32 becomes realy slow on the latest kernels

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-Id: <20061209223616.356229cc.akpm@osdl.org>
Date:	Sat, 9 Dec 2006 22:36:16 -0800
From:	Andrew Morton <akpm@...l.org>
To:	manz@...es.de
Cc:	linux-kernel@...r.kernel.org, linux-scsi@...r.kernel.org
Subject: Re: SCSI Controler SCRU32 becomes realy slow on the latest kernels

> On Thu, 7 Dec 2006 14:28:44 +0100 Hartmut Manz <manz@...es.de> wrote:
> I am using here 2 machines with the ICP Vortex SCSI-Controler SCRU32 for some 
> years now.
> 
> After switching one machine from Debian 3.1 (sarge, with Kernel 2.6.8) to the 
> upcoming Debian 4.0 (etch with Kernel 2.6.17 or 2.6.18) I have noticed that 
> my scsi-devices become very slow while there is also a dramatical increase in
> the sys time needed for I/O operations.
> 
> The machine is a dual processor Xeon system (2 * 2.2 GHz) with 2 GB memory.
> The used scsi drives are seagate R10k and R15k disks.
> 
> i.e.  reading 1 GB from the first SCSI drive takes about:
> xen-1:/var/log# time dd if=/dev/sda bs=256k count=4000 of=/dev/null
> 4000+0 records in
> 4000+0 records out
> 1048576000 bytes (1.0 GB) copied, 55.3079 seconds, 19.0 MB/s
> 
> real    0m55.361s
> user    0m0.368s
> sys     0m49.107s

ouch.

> There are two strange things: 
>    1. The transfer rate is only 19 MB/sec what is very low for this machine.
>        The expected value would be at least 50 MB/sec.
> 
>    2. the system time is in the same range as the real time and thats
>        realy annoying,  on the old kernel the system time for such an operatin
>        was about 7 sec.
> 

It would help a lot of we can determine where the kernel is spending all this
time.  Can you please generate a kernel profile?

Start a large IO operation then, while it is running, run

#!/bin/sh
sudo opcontrol --stop
sudo opcontrol --shutdown
sudo rm -rf /var/lib/oprofile
sudo opcontrol --vmlinux=/boot/vmlinux-$(uname -r)
sudo opcontrol --start-daemon
sudo opcontrol --start
sleep 10
sudo opcontrol --stop
sudo opcontrol --shutdown
sudo opreport -l /boot/vmlinux-$(uname -r) | head -50

(might need some adjustments for distro variation)

Thanks.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/