Well, at least it's a mystery to me. Consider the following D script:
sched:::on-cpu,
sched:::off-cpu
/ curpsinfo->pr_fname == "yes" /
{
printf ("PID: %d TID: %d STATE: %c\n", curpsinfo->pr_pid,
curlwpsinfo->pr_lwpid, curlwpsinfo->pr_sname);
}
sched:::enqueue,
sched:::dequeue
/ args[1]->pr_fname == "yes" /
{
printf ("PID: %d TID: %d STATE: %c\n", args[1]->pr_pid,
args[0]->pr_lwpid, args[0]->pr_sname);
}
I the start the D script, and after I'm sure the probes are
instrumented, I start the following command in another window:
yes > /dev/null
which causes the following output from my D program:
dtrace: script 'rl3.d' matched 8 probes
CPU ID FUNCTION:NAME
0 45 setbackdq:enqueue PID: 1618 TID: 1 STATE: O
0 47 disp:dequeue PID: 1618 TID: 1 STATE: R
0 45 setbackdq:enqueue PID: 1618 TID: 1 STATE: O
0 47 disp:dequeue PID: 1618 TID: 1 STATE: R
0 45 setbackdq:enqueue PID: 1618 TID: 1 STATE: O
0 47 disp:dequeue PID: 1618 TID: 1 STATE: R
...
This output continues just like this until I stop either the D script or
the "yes" command. The fact that off-cpu never fires doesn't entirely
surprise me. I'm running on a T2000 with very little other activity, so
I figure that each time the quantum runs out (sched policy TS), the
thread just stays there and starts a new quantum.
I also think I may understand why on-cpu never fired. Is it because
the thread would have gone "on-cpu" when it was fork'd and it was still
the shell executable? And then since the "yes" command is already in
memory, no IO interrupt is needed to exec the "yes" command, so the
thread never loses the processor?
The one that I can't explain away is why, when dequeue fires, pr_sname
indicates that the thread is in the R or runnable state, which according
to the DTrace guide, should mean that the thread is runnable, but not
currently running. If the state of the thread is switching from "R" to
"O", over and over again, as the output would indicate, why aren't
off-cpu and on-cpu firing? Of course, why is the thread switching to
"R" anyway, if it never has to give the processor to another thread?
Thanks,
Chip
_______________________________________________
dtrace-discuss mailing list
dtrace-discuss@opensolaris.org
