Get rid of mostly-useless proc provider probes.

[markj]

Summary

These probes are specific to FreeBSD, and provide exactly the same info
as the corresponding fbt probes for the ctor/dtor/init functions.

[rpaulo]

The FBT probes depend on how the code is laid out and if the function name changes, so will the FBT probe. The other problem with FBT probes is when the functions move from global to static and the FBT probe disappears (because the function is no longer defined or because it was inlined by the compiler).
The proc provider was providing a stable D interface, but I'm not sure how many people are useful and that's why I would be reluctant to remove it.

[markj]

In D2169#4, @rpaulo wrote:

The FBT probes depend on how the code is laid out and if the function name changes, so will the FBT probe. The other problem with FBT probes is when the functions move from global to static and the FBT probe disappears (because the function is no longer defined or because it was inlined by the compiler).

That's true in general, but in this case the three functions are arguments to uma_zcreate(), so they won't be inlined.

The proc provider was providing a stable D interface, but I'm not sure how many people are useful and that's why I would be reluctant to remove it.

Ok. These probes just seemed rather ad-hoc to me, since they're not documented anywhere, they aren't in Solaris, and they aren't obviously useful. They don't really fit in with the rest of the proc probes either, since they don't correspond to any user-visible process events. I'd like to have a UMA equivalent to the dtmalloc provider, and that would supersede these probes too.

It doesn't hurt to keep them around I suppose. I don't think they should be documented though.

[rpaulo]

In D2169#6, @markj wrote:

Ok. These probes just seemed rather ad-hoc to me, since they're not documented anywhere, they aren't in Solaris, and they aren't obviously useful. They don't really fit in with the rest of the proc probes either, since they don't correspond to any user-visible process events. I'd like to have a UMA equivalent to the dtmalloc provider, and that would supersede these probes too.

Why aren't they useful? Because of the FBT probes?

[markj]

In D2169#7, @rpaulo wrote:

In D2169#6, @markj wrote:

Ok. These probes just seemed rather ad-hoc to me, since they're not documented anywhere, they aren't in Solaris, and they aren't obviously useful. They don't really fit in with the rest of the proc probes either, since they don't correspond to any user-visible process events. I'd like to have a UMA equivalent to the dtmalloc provider, and that would supersede these probes too.

Why aren't they useful? Because of the FBT probes?

They might be useful, but I can't think of any reason to use them: there are already higher-level proc probes to track process creation and exit events, and there are FBT probes for the ctor/dtor/init/fini functions for the proc zone.

Moreover, the proc zone uses the UMA_ZONE_NOFREE flag, which means that proc zone slabs will never be reclaimed (i.e. proc_fini is never called), so proc_init is going to get called a small and bounded number of times.

[emaste]

Ping