linux-kernel - Re: Lower HD transfer rate with NCQ enabled?

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] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 5 Apr 2007 12:45:14 -0400
From:	lsorense@...lub.uwaterloo.ca (Lennart Sorensen)
To:	Mark Lord <lkml@....ca>
Cc:	Phillip Susi <psusi@....rr.com>, Chris Snook <csnook@...hat.com>,
	Paa Paa <paapaa125@...mail.com>, linux-kernel@...r.kernel.org
Subject: Re: Lower HD transfer rate with NCQ enabled?

On Thu, Apr 05, 2007 at 12:11:57PM -0400, Mark Lord wrote:
> For personal systems, yes.  For servers, probably not a bug.
> 
> Disabling readahead means faster execution queued commands,
> since it doesn't have to "linger" and do unwanted read-ahead.
> So this bug is a "feature" for random access servers.
> And a big nuisance for everything else.

Sounds like a trade off between doing read ahead on the current track,
or immediately starting to seek to the track for the next request in the
queue.  After all reading ahead on the current track means you can't
start seeking to the next request yet.

I agree it does sound like a feature.  Let the user/OS decide if read
aheads should be done by queueing them if wanted, and not queueing them
if not wanted.  Seems simple enough.  Also avoids poluting the cache
with unwanted data at the expense of potentially wanted data that was
already in the cache.

--
Len Sorensen
-
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/