At 1:07 AM +0100 2003/02/05, [EMAIL PROTECTED] wrote:
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 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.
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.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.
--
Brad Knowles, <[EMAIL PROTECTED]>
"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 [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
