Date: Fri, 11 Apr 2003 15:25:38 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Peter Jeremy <peterjeremy@optushome.com.au> Cc: freebsd-hackers@freebsd.org Subject: Re: Solaris 2.x compat. system accounting, sarcheck for fbsd(commercial) Message-ID: <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>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3E9740E2.E27EFD30>