[dtrace-discuss] kcopy() untraceble on X4500/b65 ?

[Jon Haslam]

Hi Paul,

> Trying the figure out who is calling kcopy() I tried:
> #  dtrace -n 'fbt::kcopy:entry { @[stack(2)] = count()}'
> But the only output I got was:
>
> dtrace: description 'fbt::kcopy:entry ' matched 1 probe
>
> And ^C after a while gave no output....
>
>
> Any tips on how to figure out why kcopy() is saturating 3 opteron 
> cores ??

The reason you don't see kcopy:entry firing is because we often
enter kcopy() by jumping in part way through (for performance
reasons I think). For example, your system is seeing a lot
of kcopy() activity eminating from uiomove() (For the viewers at
home I verified this by having a quick look at the system in
question). If we look at uiomove() we can see it actually calls
kcopy_nta():

 > uiomove::dis ! grep kcopy
uiomove+0x89:                   call   -0x17dbae        <kcopy_nta>
uiomove+0xa1:                   call   -0x17dbc6        <kcopy_nta>

The kcopy_nta() function uses kcopy() but it doesn't call it
directly but simply jumps part way into it:

 > kcopy_nta::dis ! grep kcopy+
kcopy_nta+0x18:                 jne    -0x56    <kcopy+0x14>
kcopy_nta+0x21:                 jb     -0x5f    <kcopy+0x14>
kcopy_nta+0x34:                 jne    -0x72    <kcopy+0x14>


Therefore you never actually hit the kcopy:entry probe you have enabled.
If you instrument kcopy:return then you should see the actual call
sites as we do always exit via that route.

Jon.