thorpej@zembu.com (Jason R Thorpe) writes:
>  > > It's not like you're counting it "against the process".  But profiling
>  > > is supposed to tell you where a process is spending its time, and if your
>  > > process is I/O bound, you want to know exactly how much time is spend in
>  > > those I/O routines.  We currently don't have that.
>  > 
>  > Then you probably want to separate iowait time from just sleeping.
> 
> So, what's i/o wait time?  File system I/O?  Network I/O?  What about
> I/O as a result of a page fault?  What about some other kind of
> long-to-complete system call?
> 
> I think counting this time is perfectly legit, you want to know how
> you got to that sleep and how long it took.

but, one of the things that I _don't_ think makes sense to count here
is time spent sleeping because you were context switched away from
(because some other process was higher priority).

That would totally screw up profiling compute-bound processes, since
whichever unlucky function was the victim of the context switch could
be charged a Lot of time, when it fact it might want to take next to
none.


really, what you want to charge is:

* for "voluntary" context switches (i.e. context switches while
waiting for data to become available, etc.), the time between going to
sleep and when you would wake up if you were the only process on the
system (i.e., the time until you're put back on a run queue).

* for involuntary context switches, caused by scheduling some
higher-priority process, nothing.



cgd