Skip site navigation (1)Skip section navigation (2)
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>