In message <a05200f08ba65f714a4e9@[146.106.12.76]>, Brad Knowles writes: >At 10:44 PM +0100 2003/02/04, Poul-Henning Kamp wrote: > >> In difference from the devstat framework which measures how big a >> percentage of the time a drive has one or more outstanding requests, >> I think that measuring the responstime is a much more useful metric. >> (comments, input, references welcome) > > This is queue depth versus latency, right? I don't suppose a >request to provide both would hold any weight with you, would it?
I'm 100% wide open to suggestions. Anything I can trivally account for is fair game. 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. Ohh, another thing I should add: 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. Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
