linux-kernel - Re: SATA NCQ - blessing for throughput, curse for latency?

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 PHC
Open Source and information security mailing list archives

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

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

Date:	Wed, 11 Nov 2009 12:00:17 +0100
From:	Corrado Zoccolo <czoccolo@...il.com>
To:	Przemysław Pawełczyk 
	<przemyslaw@...elczyk.it>
Cc:	lkml <linux-kernel@...r.kernel.org>
Subject: Re: SATA NCQ - blessing for throughput, curse for latency?

Hi,
2009/11/11 Przemysław Pawełczyk <przemyslaw@...elczyk.it>:
> Hi,
>
> [snip] I wrote a script (that is pasted
> at the end), which using zcav from bonnie++ (and unbuffer from expect
> to work properly if output is redirected to a file) reads up to 64 GB
> of the disk, but after a first few gigabytes (depending on how many GB
> of memory you have) cats kernel sources with binary files up to the
> second level of directory depth. What is measured? The real time of
> the cat to /dev/null operation. Why not the kernel sources alone?
> Because if we build kernel, especially with -jX (where X > 1), then
> both inodes and contents of the corresponding files within these
> directories generally won't be consecutive. Time for the results with
> some background information. In my tests I have used 2.6.31.5 built
> with debuginfo (using debian's make-kpkg).
>
>[summarized the relevant numbers]
> *** NCQ turned on ***
> real 752.30
> user 0.20
> sys 1.83
>
>
> *** NCQ turned off *** (kernel booted with noncq parameter)
> real 62.30
> user 0.27
> sys 1.59
>
> [snip]
>
> Can anyone confirm analogous NCQ-dependant behavior with other
> disk/controller variants? Any suggestions for improvements other than
> turning off NCQ or switching to anticipatory (in typical cases cfq is
> better, so it's not the best option)?

The NCQ latency problem is well known, and should be fixed in 2.6.32.
You can try building the latest rc.

-- 
__________________________________________________________________________

dott. Corrado Zoccolo                          mailto:czoccolo@...il.com
PhD - Department of Computer Science - University of Pisa, Italy
--------------------------------------------------------------------------
--
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/