From owner-cvs-all Sun Feb 1 08:20:57 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA27313 for cvs-all-outgoing; Sun, 1 Feb 1998 08:20:57 -0800 (PST) (envelope-from owner-cvs-all@FreeBSD.ORG) Received: from pluto.plutotech.com (mail.plutotech.com [206.168.67.137]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA27057; Sun, 1 Feb 1998 08:19:06 -0800 (PST) (envelope-from gibbs@plutotech.com) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.8.7/8.8.5) with ESMTP id JAA19224; Sun, 1 Feb 1998 09:18:26 -0700 (MST) Message-Id: <199802011618.JAA19224@pluto.plutotech.com> X-Mailer: exmh version 2.0.1 12/23/97 To: Mike Smith cc: "Justin T. Gibbs" , Bruce Evans , toor@dyson.iquest.net, cvs-all@FreeBSD.ORG, cvs-committers@FreeBSD.ORG, cvs-sys@FreeBSD.ORG Subject: Re: cvs commit: src/sys/i386/isa wfd.c In-reply-to: Your message of "Sun, 01 Feb 1998 23:40:26 +1030." <199802011310.XAA05676@word.smith.net.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 01 Feb 1998 09:15:46 -0700 From: "Justin T. Gibbs" Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk X-To-Unsubscribe: mail to majordomo@FreeBSD.org "unsubscribe cvs-all" >I can think of quite a few more things that would be useful to extract >in a generalised fashion. (eg. idle timeouts, max queue length, &c.) Would these be interesting to you as a user, or to other areas of the kernel? The function John was proposing was for giving hints to the system. You can pull many other I/O stats with the "devstat" interface Ken Merry added to CAM. There's nothing CAM specific about it and devstat is intended to replace the "dk" stuff. Ken looked at upgrading the wd driver to use devstat a while back, but that driver touches statistics in lots of places, so it's not completely straight forward to do. I don't know if max queue length would help any portions of the kernel much. In CAM, the queue depth on the device is maxed out (30-63 transactions usually) but any additional buffers are also sorted. The system doesn't usually exceed the device's queue unless there is something like a sync, and queuing those extra buffers early so they can be "bufqsort"ed is a win. >You hinted that CAM offers a mechanism for this sort of extraction; can >we standardise on something like that & perhaps mutate it back onto the >legacy drivers? I'm really not interested in porting anything back to the legacy drivers. The code is just too different to be practical and I have limited enough time as it is just to work on CAM. >-- >\\ Sometimes you're ahead, \\ Mike Smith >\\ sometimes you're behind. \\ mike@smith.net.au >\\ The race is long, and in the \\ msmith@freebsd.org >\\ end it's only with yourself. \\ > > > -- Justin