TSLOG(4)

πŸ“¦
version 15.1 Β· 2 versions
, in freebsd 15.1, nixpkgs unstable

✨ TSLOG(4) β€” the boot-time event tracing facility, bestie ✨

okay so real talk, this one's called tslog and it lives in the Kernel Interfaces Manual. it's a boot-time event tracing facility and honestly? it's giving main character energy for anyone who's ever stared at a slow FreeBSD boot like 😭


🌸 SYNOPSIS 🌸

so to like, actually get this boot-time event tracing facility compiled into your kernel, you drop this line into the kernel config file. that's it. that's the whole vibe:

option TSLOG

πŸ’– DESCRIPTION πŸ’–

tslog is a boot-time event tracing facility. it's literally built for tracing recursive events based on function entries and exits β€” like, function goes in, function comes out, tslog is writing it all down 🫢

and why, you ask? because its whole purpose is to make it easier to pinpoint and shrink your overall FreeBSD boot time by generating detailed timing information. it's a whole forensic vibe check for your boot process, no cap.

here's the slay part: tslog can trace the boot loader, kernel initialization, and userland processes. all three. ate and left no crumbs.

in userland, it records these details for each process ID. periodt:

  • the timestamp of the fork(2) which creates the given process ID, plus the parent process ID
  • the path passed to execve(2), if there is one
  • the first path resolved by namei(9), if any
  • the timestamp of the exit(3) which terminates the process

like, it's keeping receipts on every single one of those πŸ’…


πŸ¦‹ SYSCTL VARIABLES πŸ¦‹

these sysctl(8) variables are available, and yes you should know them:

  • debug.tslog β€” dumps the tslog buffer of recorded loader and kernel event timestamps. it's the kernel/loader tea β˜•
  • debug.tslog_user β€” dumps the tslog buffer of recorded userland event timestamps. separate pile of receipts, for userland πŸŽ€

πŸ”₯ FLAMEGRAPHS πŸ”₯

okay so the tslog buffer dumps can be used to generate flamegraphs of the FreeBSD boot process for visual analysis. literally so pretty and so useful. see https://github.com/cperciva/freebsd-boot-profiling for more information β€” iykyk 🌈


πŸ‘‘ SEE ALSO πŸ‘‘

dtrace(1), boottrace(4), ktr(4) β€” go read those too bestie, the crossover episode is real πŸ“


πŸ’œ HISTORY πŸ’œ

tslog first appeared in FreeBSD 12.0. support for tracing boot loaders and userland process was added in FreeBSD 13.2. glow-up, honestly ✨

🧚 TSLOG vs. Boottrace 🧚

tslog is oriented towards system developers, while boottrace(4) is meant to be easy to use by system administrators. both facilities provide an overview of timing and resource usage of the boot process β€” different audiences, same chaotic boot energy πŸ’€

⭐ TSLOG vs. DTrace ⭐

dtrace(1) is not always the right tool for profiling early kernel initialization. the reason? it requires some kernel subroutines which are not yet available early in the boot process, e.g.: traps, memory allocation, or thread scheduling. tslog depends on fewer kernel subroutines than dtrace(1), and because of that it can trace early kernel initialization. like, it gets in there earlier. iconic πŸŽ€

🌸 TSLOG vs. KTR 🌸

ktr(4) has a couple of limitations which prevent it from being able to run at the start of the boot process. in contrast, tslog is designed for logging timestamped events for boot profiling. it's literally the whole point 🫢


πŸŽ€ AUTHORS πŸŽ€

tslog was written by Colin Percival <cperciva@FreeBSD.org>.

this manual page was written by Mateusz Piotrowski <0mp@FreeBSD.org>.


and that's the whole page bestie, every flag, every sysctl, every fork(2) receipt accounted for πŸ’… no cap, nothing skipped.

sign-off time 🫢 this gorgeous thing is from the Debian flavor of the manual, dated June 1, 2022, and it's page TSLOG(4). mwah πŸ’‹

πŸ“¦ where this page comes from