If you are going to fix it, could you add a microstate for iowait so
we have an accurate per process measure of blocked on diskio. I think
I filed a bug on this about 5 years ago or more... We already have a
microstate for page-in wait.

Adrian

On 10/18/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
Adrian,
biowait() still updates cpu_stats.sys.iowait.  This means that Solaris
is still keeping track of the number of threads that are blocked waiting
for I/O.  I see no reason not to expose this value to the user.
I certainly do not intend to re-introduce a CPU percentage of time
waiting for I/O, however.

-j


On Wed, Oct 18, 2006 at 05:37:15PM -0700, adrian cockcroft wrote:
> The algorithm for iowait used to be something like: if idle and vmstat
> b nonzero then iowait
> So on Solaris 10, vmstat b is gone as well as iowait. If you want to
> see how much time you are waiting for io, use iostat and add up the
> times for each disk.
>
> Here is one way it was broken, a cpu starts an io, a different cpu
> completes the io, which cpu was waiting?
>
> Adrian
>
> On 10/18/06, Mike Gerdts <[EMAIL PROTECTED]> wrote:
> >On 10/18/06, adrian cockcroft <[EMAIL PROTECTED]> wrote:
> >> In Solaris 10, iowait is no longer measured and will be reported as
> >> zero by existing tools. Since iowait was always a variant of idle
> >> time, this makes no difference to usr or sys time.
> >> iowait was always a confusing and useless metric, which is why it was
> >removed.
> >
> >On a related note, I have yet to see vmstat's "b" (kernel threads
> >blocked on I/O) column be non-zero.  This includes a large RAC
> >environment where the previous measure of I/O health was (don't shoot
> >the messenger!) iowait.   The same workload on S9 consistently showed
> >non-zero values in the "b" column.
> >
> >Has the meaning of this value changed as well, or is Solaris 10 just
> >that much better at getting I/O out of the queue?
> >
> >TIA,
> >Mike
> >
> >--
> >Mike Gerdts
> >http://mgerdts.blogspot.com/
> >
> _______________________________________________
> perf-discuss mailing list
> perf-discuss@opensolaris.org

_______________________________________________
perf-discuss mailing list
perf-discuss@opensolaris.org

Reply via email to