| 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
| ||
|
Message-ID: <20070405164514.GF3510@csclub.uwaterloo.ca> 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/
Powered by blists - more mailing lists