Date: Wed, 20 Jan 1999 01:35:14 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: Matthew Jacob <mjacob@feral.com> Cc: "Kenneth D. Merry" <ken@plutotech.com>, cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG Subject: Re: cvs commit: src/sys/cam cam_xpt.c Message-ID: <199901200935.BAA00875@apollo.backplane.com> References: <Pine.LNX.4.04.9901192345350.22998-100000@feral-gw>
next in thread | previous in thread | raw e-mail | index | archive | help
:
:The latter I'd believe. The former I question. I seriously doubt that a
:lot of drives have the moxie to effectively do a generation based
:staggered elevator the correctly balances performance with latency.
: -matt
That actually isn't quite what I was refering to. The kernel already runs
I/O ops through an elevator algorithm. Unfortunately, the elevator
algorithm isn't optimal for a modern drive with a meg of on-board cache.
Significant performance gains using lots of tags occur in several
situations:
* The kernel does not do a good job prioritizing reads with pending writes
present, especially ordered pending writes. With a lot of tags, the
drive can handle this optimally. Without tags, read performance is
seriously degraded in the face of writes.
* The drive knows the physical layout of the disk better then the kernel.
For example, many drives store sectors in reverse order on any given
track to optimize cache fill / DMA operations.
* The drive may implement a split or zoned cache. The elevator algorithm
the kernel tries to do may not be optimal for the cache configuration.
With a lot of tags, the drive can match read requests to the cache
configuration and retire cache hits instantly.
The kernel has no idea what the drive may have in its cache. The
drive could very well have a sector in its cache that the kernel
would have otherwise delayed commiting the request for due to the
elevator algorithm.
* In general terms, the bigger the drive's on-board cache, the more
appropriate it is to let the drive order the requests rather then
the kernel.
A lot of drives implement sufficient sophistication in their tag and
cache handling to make using a lot of tags worthwhile. Enough that using
lots of tags really should be the default. Of course, some drives
have firmware bugs, so the Quirks mechanism is a necessity.
-Matt
Matthew Dillon
<dillon@backplane.com>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199901200935.BAA00875>