Date: Fri, 11 Apr 2003 22:04:33 -0500 From: Dan Nelson <dnelson@allantgroup.com> To: Terry Lambert <tlambert2@mindspring.com> Cc: freebsd-hackers@freebsd.org Subject: Re: Solaris 2.x compat. system accounting, sarcheck for fbsd(commercial) Message-ID: <20030412030433.GI19751@dan.emsphone.com> In-Reply-To: <3E9740E2.E27EFD30@mindspring.com> References: <20030411060823.GA27575@titan.klemm.apsfilter.org> <20030411080102.GC47320@cirb503493.alcatel.com.au> <3E96E5AE.548EBC6@mindspring.com> <20030411211359.GC31752@cirb503493.alcatel.com.au> <3E9740E2.E27EFD30@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In the last episode (Apr 11), Terry Lambert said: > In theory, this could be fixed, you're saying. I don't believe this. > You need to know that a particular I/O as a result of a page fault is > a result of a process, rather than system (e.g. swapping). Because > the VM and buffer cache is unified, you can't do this. In SVR4, you > know because you know the buffer cache operation is waiting on a VM > operation, and buffers are attributable to processes. See what I > mean? You could disguingish "idle" vs "i/o wait" per-process by classifying all the wait channels, couldn't you? I'd guess that anything in /sys/vm/* and /sys/*fs/* could be called i/o wait, for starters. Another possibility is by sleep priority. PSWP, PVM, PINOD, PRIBIO, and PVFS all look like they're in the i/o category. If you're about to do cp_time[CP_IDLE]++ in kern_clock.c, just scan the process list and look for a process in one of the i/o-wait wchans. If you find one, increment CP_IOWAIT instead. Sure, you may have to lock allproc, but key, you're already idle :) -- Dan Nelson dnelson@allantgroup.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030412030433.GI19751>