From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 11 20:04:40 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8ED1537B401 for ; Fri, 11 Apr 2003 20:04:40 -0700 (PDT) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id D758043FAF for ; Fri, 11 Apr 2003 20:04:39 -0700 (PDT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.12.9/8.12.9) id h3C34Xvi093962; Fri, 11 Apr 2003 22:04:33 -0500 (CDT) (envelope-from dan) Date: Fri, 11 Apr 2003 22:04:33 -0500 From: Dan Nelson To: Terry Lambert Message-ID: <20030412030433.GI19751@dan.emsphone.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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3E9740E2.E27EFD30@mindspring.com> X-OS: FreeBSD 5.0-CURRENT X-message-flag: Outlook Error User-Agent: Mutt/1.5.4i cc: freebsd-hackers@freebsd.org Subject: Re: Solaris 2.x compat. system accounting, sarcheck for fbsd(commercial) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Apr 2003 03:04:40 -0000 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