Page MenuHomeFreeBSD

Get rid of mostly-useless proc provider probes.
ClosedPublic

Authored by markj on Mar 28 2015, 9:16 PM.
Tags
None
Referenced Files
Unknown Object (File)
Mon, Nov 25, 6:51 AM
Unknown Object (File)
Tue, Nov 5, 5:56 PM
Unknown Object (File)
Oct 27 2024, 6:52 PM
Unknown Object (File)
Oct 19 2024, 2:55 AM
Unknown Object (File)
Oct 9 2024, 4:42 AM
Unknown Object (File)
Oct 2 2024, 7:55 AM
Unknown Object (File)
Oct 1 2024, 8:37 AM
Unknown Object (File)
Sep 27 2024, 12:09 AM
Subscribers

Details

Summary

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

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

markj retitled this revision from to Get rid of mostly-useless proc provider probes..
markj edited the test plan for this revision. (Show Details)
markj updated this object.

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.

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.

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?

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.

rpaulo added a reviewer: rpaulo.
This revision is now accepted and ready to land.Mar 28 2015, 11:09 PM
This revision was automatically updated to reflect the committed changes.