The easiest way to do this is using the sleep/wakeup
probes in the sched provider. From the process/thread
perspective, once they issue an IO, they sit on a sleep
queue until the IO is completed, at which point they're
issued a wakeup.
io:start/io:::done is usefull for a system view, but that's
not what you're interested in.
You could also enable probes at the system call level,
and time things likd syscall::read:entry to syscall::read:return,
using predicates as needed to make sure you're measuring
what you expect.
I find your last sentence confusing;
"because the io event might take a long time to finish, before
which, the program would have gone back to the cpu"
The thread that issued the IO will not go back on-cpu until
the IO has been completed, unless the thread is using the
AIO (async IO) facility.
Thanks,
/jim
Hi,
I am trying to characterize some benchmark programs using dtrace. The
first step is to determine the time that a program spends on the CPU (doing
computations), and the time it spends doing IO. The cpu time can be easily
determined using the on-cpu and off-cpu probes. I am having trouble figuring
out the io time. Using the io:start and io:done probes will not give me the
correct numbers, because the io event might take a long time to finish, before
which, the program would have gone back to the cpu..Any ideas?
Thanks.
_______________________________________________
dtrace-discuss mailing list
dtrace-discuss@opensolaris.org
