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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.opensolaris.org/pipermail/dtrace-discuss/attachments/20090218/a0866554/attachment.html>
Chip Bennett wrote:> > 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? >Most likely the ''yes'' thread is taking a trap when its time quanta runs out and is calling preempt() to give up the cpu. When the ''yes'' thread calls preempt it is ON_PROC and it goes ahead and enqueues itself on the run queue. The enqueue probe fires before the thread state is changed to TS_RUN (R) and then the actual enqueuing happens. So when the enqueue probe fires the thread state is still ON_PROC (O). http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/disp/disp.c#1292 http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/disp/disp.c#1304 Having enqueued itself the ''yes'' thread [its state is not TS_RUN] now calls swtch() to context-switch. [swtch() determines the best thread in the run queue to context-switch to]. It might turn out that swtch() determines that the ''yes'' thread is the best candidate thread to context switch to. The best candidate thread is dequeued from the run queue [its state is TS_RUN and hence you see R when the dequeue probe fires] http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/disp/disp.c#1636 The swcth() code has an optimisation to check if the best candidate thread is the same as the thread calling swtch() and in that case it does not have to do a context-switch and hence the off-cpu probe does not fire. http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/disp/disp.c#892 You might want to add a stack() probe to the enqueue and dequeue probes above to get an idea of what is triggering the scheduling activities... Pramod> Thanks, > > Chip > > ------------------------------------------------------------------------ > > _______________________________________________ > dtrace-discuss mailing list > dtrace-discuss at opensolaris.org >
Pramod,>> Having enqueued itself the ''yes'' thread [its state is not TS_RUN] nowcalls swtch()... I assume you meant "is now TS_RUN"? I hope: otherwise, I''m confused. ;-) That was a great explanation: I really appreciate you taking the time. Chip
Chip Bennett wrote:> Pramod, > > >>> Having enqueued itself the ''yes'' thread [its state is not TS_RUN] now >>> > calls swtch()... > > I assume you meant "is now TS_RUN"? I hope: otherwise, I''m confused. > ;-) >Yes that was a typo....I meant ''is now TS_RUN''. Pramod> That was a great explanation: I really appreciate you taking the time. > > Chip > > >