Page MenuHomeFreeBSD

dtrace: stop using eventhandlers for the part compiled into the kernel
ClosedPublic

Authored by mjg on Nov 22 2020, 4:01 AM.
Tags
None
Referenced Files
Unknown Object (File)
Fri, Oct 10, 3:52 PM
Unknown Object (File)
Mon, Sep 29, 3:35 PM
Unknown Object (File)
Fri, Sep 19, 8:39 PM
Unknown Object (File)
Sep 13 2025, 11:57 AM
Unknown Object (File)
Aug 17 2025, 1:12 AM
Unknown Object (File)
Jul 20 2025, 12:51 AM
Unknown Object (File)
Jun 22 2025, 3:38 PM
Unknown Object (File)
Jun 22 2025, 2:34 AM
Subscribers

Details

Summary

Side note is that allocations sizes seem also out of whack, will be sorted out separately.

Duplication in creation of proc/thread0 will have to be sorted out as well but that's beyond the scope.

Diff Detail

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

Event Timeline

mjg requested review of this revision.Nov 22 2020, 4:01 AM
mjg created this revision.

I am fine with conversion.

What surprises me is that just the presence of the hooks implies mallocs.

That said, why not piggy-back dtrace memory on struct thread, as we already have the scheduler data placed that way, see sched_sizeof_thread() and sched_sizeof_proc(). Just put one more addend into the zone creation size argument.

sys/kern/kern_dtrace.c
87 ↗(On Diff #79844)

(void) while you are there

markj added inline comments.
sys/kern/kern_proc.c
68 ↗(On Diff #79844)

If we are going to unconditionally include this header, it would be better to define the hooks for both KDTRACE_HOOKS and !KDTRACE_HOOKS, to avoid further polluting the code with ifdefs.

This revision is now accepted and ready to land.Nov 22 2020, 6:46 PM

threads are NOFREE so this would add more memory which can't be reclaimed until reboot