From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 11 15:27:03 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 B76F437B401; Fri, 11 Apr 2003 15:27:03 -0700 (PDT) Received: from heron.mail.pas.earthlink.net (heron.mail.pas.earthlink.net [207.217.120.189]) by mx1.FreeBSD.org (Postfix) with ESMTP id F1F2643F75; Fri, 11 Apr 2003 15:27:00 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0012.cvx22-bradley.dialup.earthlink.net ([209.179.198.12] helo=mindspring.com) by heron.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 1946z3-0003l3-00; Fri, 11 Apr 2003 15:26:58 -0700 Message-ID: <3E9740E2.E27EFD30@mindspring.com> Date: Fri, 11 Apr 2003 15:25:38 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Peter Jeremy References: <20030411060823.GA27575@titan.klemm.apsfilter.org> <20030411080102.GC47320@cirb503493.alcatel.com.au> <3E96E5AE.548EBC6@mindspring.com> <20030411211359.GC31752@cirb503493.alcatel.com.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a4681c1e18a9955c87c01718e6e7334593a2d4e88014a4647c350badd9bab72f9c350badd9bab72f9c 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: Fri, 11 Apr 2003 22:27:04 -0000 Peter Jeremy wrote: > ["Wait for I/O" state] > On Fri, Apr 11, 2003 at 08:56:30AM -0700, Terry Lambert wrote: > >The intent is to say "I would be running some process X, but I'm > >idle because I'm waiting for I/O". > > Virtually every non-running Unix process is waiting for some sort of > I/O - be it an incoming network connection or a keypress. It > therefore makes more sense to restrict this state to mean that a > process is either involuntarily waiting (eg a page fault has occurred) > or it's waiting on filesystem I/O (since there's no way for a process > to determine whether a particular I/O request to a file will cause > the process to block). AFAIK, SysV accumulates "wait for I/O" when > it is unable to schedule any process and at least one process is > in this "involuntarily blocked" state. Yes. I thought that that's what I said. 8-). > >Part of the problem in reporting this in FreeBSD is the inability > >to attribute pending I/O requests e.g. as the result of a fault > >by a process or as a result of a fault by the kernel itself. > > I'm not sure that this matters. In either case, the process does > not want to block. If it is blocked then it represents a situation > which the system administrator may be able to mitigate (throw more > hardware at the problem or alter file distribution across available > spindles). The problem is that you can't accumulate this number unless you know that it's a process that's blocked waiting for I/O. If all you have is a VM fault, in the limit, then you can't do anything about this. For FreeBSD in the normal case, you probably would not see any time accumulate except for directory I/O, which uses block I/O primitives. Eveything else is, in theory, paging. > If your system is doing a CVSup or buildworld then any idle time is > wait for I/O. Or a wait for a process to complete ("-j 8", whatever). You can't account it properly at all, I don't think. > In a webserver or database server (for example), > FreeBSD doesn't have any way to differentiate between CPU idle because > there are no outstanding requests and CPU idle because all of the > outstanding requests are blocked waiting for file I/O. 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? If you still disagree, then you should probably implement the code to get this statistic, since if you're right, it would be trivial. -- Terry