History log of /freebsd-current/sys/kern/kern_tslog.c
Revision Date Author Comments
# fdafd315 24-Nov-2023 Warner Losh <imp@FreeBSD.org>

sys: Automated cleanup of cdefs and other formatting

Apply the following automated changes to try to eliminate
no-longer-needed sys/cdefs.h includes as well as now-empty
blank lines in a row.

Remove /^#if.*\n#endif.*\n#include\s+<sys/cdefs.h>.*\n/
Remove /\n+#include\s+<sys/cdefs.h>.*\n+#if.*\n#endif.*\n+/
Remove /\n+#if.*\n#endif.*\n+/
Remove /^#if.*\n#endif.*\n/
Remove /\n+#include\s+<sys/cdefs.h>\n#include\s+<sys/types.h>/
Remove /\n+#include\s+<sys/cdefs.h>\n#include\s+<sys/param.h>/
Remove /\n+#include\s+<sys/cdefs.h>\n#include\s+<sys/capsicum.h>/

Sponsored by: Netflix


# 0a713948 22-Nov-2023 Alexander Motin <mav@FreeBSD.org>

Replace random sbuf_printf() with cheaper cat/putc.


# 685dc743 16-Aug-2023 Warner Losh <imp@FreeBSD.org>

sys: Remove $FreeBSD$: one-line .c pattern

Remove /^[\s*]*__FBSDID\("\$FreeBSD\$"\);?\s*\n/


# 02d90458 21-May-2023 Colin Percival <cperciva@FreeBSD.org>

tslog: Handle curthread equal to NULL

Early in the kernel boot, curthread goes through three stages:

1. Kernel crash when you try to access it, because PCPU doesn't exist.
2. NULL, because PCU exists but isn't initialized.
3. &thread0, which is where most of the kernel boot process runs.

This broke TSLOG from inside hammer_time since the scripts which parse
logged records didn't understand that NULL meant &thread0.

Tell tslog to record &thread0 as the active thread if passed NULL.

Sponsored by: https://www.patreon.com/cperciva
Differential Revision: https://reviews.freebsd.org/D40324


# 2406867f 20-Mar-2022 Colin Percival <cperciva@FreeBSD.org>

tslog: Add CTLFLAG_SKIP to sysctls

The timestamp logs are quite large (often much larger than all the
other sysctls combined) so it's unlikely anyone will want to have
them displayed by `sysctl -a`.

MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D34616


# 52e125c2 17-Oct-2021 Colin Percival <cperciva@FreeBSD.org>

TSLOG: Report final execname, not first

In cases such as daemons launched via limits(1), a process may call
exec multiple times; the last name of the last binary executed is
usually (always?) more informative.

Fixes: 46dd801acb23 Add userland boot profiling to TSLOG
Sponsored by: https://www.patreon.com/cperciva


# 46dd801a 16-Oct-2021 Colin Percival <cperciva@FreeBSD.org>

Add userland boot profiling to TSLOG

On kernels compiled with 'options TSLOG', record for each process ID:
* The timestamp of the fork() which creates it and the parent
process ID,
* The first path passed to execve(), if any,
* The first path resolved by namei, if any, and
* The timestamp of the exit() which terminates the process.

Expose this information via a new sysctl, debug.tslog_user.

On kernels lacking 'options TSLOG' (the default), no information is
recorded and the sysctl does not exist.

Note that recording namei is needed in order to obtain the names of
rc.d scripts being launched, as the rc system sources them in a
subshell rather than execing the scripts.

With this commit it is now possible to generate flamecharts of the
entire boot process from the start of the loader to the end of
/etc/rc. The code needed to perform this processing is currently
found in github: https://github.com/cperciva/freebsd-boot-profiling

Reviewed by: mhorne
Sponsored by: https://www.patreon.com/cperciva
Differential Revision: https://reviews.freebsd.org/D32493


# fe51b5a7 30-May-2021 Colin Percival <cperciva@FreeBSD.org>

kern_tslog: Include tslog data from loader

The i386 loader (and hopefully others to come) now passes tslog data
as a "preloaded module". Include this in the data returned by the
debug.tslog sysctl.

Reviewed by: kevans


# e31e7199 31-Dec-2017 Colin Percival <cperciva@FreeBSD.org>

Code for recording timestamps of events, especially function entries/exits.
This is a very primitive system, intended for use in measuring performance
during the early system boot, before more sophisticated tools like DTrace
or infrastructure like kernel memory allocation and mutexes are available.

Because this code records pointers to strings rather than copying strings
(in order to keep the memory usage more manageable), if a kernel module is
unloaded after logging an event, Bad Things can happen. Users are advised
to not do that.

Since cycle counts from the early kernel boot are used as an initial entropy
source, publishing this information to userland could result in inadequate
entropy being kept private to the kernel RNG. Users are advised to not
enable this on systems with untrusted users.

Discussed on: freebsd-current