Hi Robert,

I am trying to get documentation how how this lazyloading happens when you are dealing with dtrace probes being added to user applications. In particular if it somehow avoids the overhead of registering dtrace probes when they aren't needed, how does it know if they are needed, etc...

Unfortuntely, lazy loading isn't documented (FWIW, there is an open
bug for this - 6818262: Need to document the '-xlazyload' option).

By specifying lazy loading with the the '-xlazyload' option we
no longer load any helper DOF when the executable starts up.
This means that any USDT based probes available for the
process in question won't be visible with a 'dtrace -l' as
they normally would be. However, if you go and explicitly
try and enable USDT probes that are contained in the
executable, we will then load them into the kernel and create
them on-demand. An example of this is the plockstat
provider which sits in libc. We certainly don't want to
register the plockstat provider and create probes for every
single process that starts up! Only when you explictly
reference the plockstat provider for a running process will
we create the specified probes.

The upside of this is, as you say, we don't suffer any
run time overhead that is caused by registering USDT probes
when the process starts up. This is not normally an issue
for processes that stay around for a while. However, if
you have a process that contains USDT probes which may be
exec'd frequently then you really need to be lazy loading
to avoid potential scalability issues on process startup
and exit.

Let me know if you have any questions.

dtrace-discuss mailing list

Reply via email to