From owner-freebsd-current Tue Feb 4 16:39:13 2003 Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 486C637BFFA; Tue, 4 Feb 2003 16:39:09 -0800 (PST) Received: from picard.skynet.be (picard.skynet.be [195.238.3.88]) by mx1.FreeBSD.org (Postfix) with ESMTP id 177CA43E4A; Tue, 4 Feb 2003 16:39:08 -0800 (PST) (envelope-from brad.knowles@skynet.be) Received: from [146.106.12.76] (ip-26.shub-internet.org [194.78.144.26] (may be forged)) by picard.skynet.be (8.12.7/8.12.7/Skynet-OUT-2.21) with ESMTP id h150cnHh004637; Wed, 5 Feb 2003 01:38:50 +0100 (MET) (envelope-from ) Mime-Version: 1.0 X-Sender: bs663385@pop.skynet.be Message-Id: In-Reply-To: <27759.1044403667@critter.freebsd.dk> References: <27759.1044403667@critter.freebsd.dk> Date: Wed, 5 Feb 2003 01:37:54 +0100 To: phk@freebsd.org From: Brad Knowles Subject: Re: Preview: GEOMs statistics code. Cc: Brad Knowles , current@freebsd.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG At 1:07 AM +0100 2003/02/05, phk@freebsd.org wrote: > I don't have a queue-depth as such, but I have number of transactions > in transit. Will a snapshot of that at the time of the read do > what you want ? I am too sleepy to know if that will allow you to > calculate the average number of outstanding requests precisely. I would think that should do just fine. So long as we can get some sense of %busy (and %wait) as well as average service times (over the sample period), that should let us fill out those last columns in `iostat -x`. > I won't be locking the stats counters, so reads may get inconsistent > results. > > There is no risk for the updates, because all the updating happens in > the g_up thread, so there is no contention for changing the kernel > fields. > > The risk is that the copy passed to userland may happen in the > middle of an update and therefore have a field with a weird value > which will look OK at the next reading. > > The risk is quite small because the g_up thread has higher priority than > anything coming in from userland will ever have. This is the same kind of risk that we have with `ps`, right? In that the data is in the process of changing as we are reading it, so you can't always take the data it prints out too literally? IMO, that's a perfectly fine limitation to live with, for the results that it allows us to get. -- Brad Knowles, "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message