From owner-cvs-all Wed Jan 20 01:35:30 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id BAA02519 for cvs-all-outgoing; Wed, 20 Jan 1999 01:35:30 -0800 (PST) (envelope-from owner-cvs-all@FreeBSD.ORG) Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id BAA02511; Wed, 20 Jan 1999 01:35:27 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.2/8.9.1) id BAA00875; Wed, 20 Jan 1999 01:35:14 -0800 (PST) (envelope-from dillon) Date: Wed, 20 Jan 1999 01:35:14 -0800 (PST) From: Matthew Dillon Message-Id: <199901200935.BAA00875@apollo.backplane.com> To: Matthew Jacob Cc: "Kenneth D. Merry" , cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG Subject: Re: cvs commit: src/sys/cam cam_xpt.c References: Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk : :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 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message