Skip to content

Document the boottime calls - #388

Draft
nicholasberlin wants to merge 4 commits into
mainfrom
boottime-manpages
Draft

Document the boottime calls#388
nicholasberlin wants to merge 4 commits into
mainfrom
boottime-manpages

Conversation

@nicholasberlin

Copy link
Copy Markdown
Contributor

Split out of #372; this carries only the documentation.

Manpages for quark_update_boottime(3), quark_get_boottime(3) and quark_time_to_wallclock(3), listed in quark(7), with the HTML docs and README.md regenerated. The pages document which times are expressed since boot, that btime comes from /proc/stat and moves on clock steps, and two common ways of detecting a step (polling the CLOCK_REALTIME - CLOCK_BOOTTIME delta, or a timerfd armed with TFD_TIMER_CANCEL_ON_SET). Each page carries a HISTORY section noting the calls appeared in quark 0.8, when all times handed out by quark switched from epoch to since-boot, so readers on older versions aren't misled.

mandoc -Tlint passes on the new pages.

@nicholasberlin

nicholasberlin commented Aug 14, 2026

Copy link
Copy Markdown
Contributor Author

Pushed 4d96cf0 documenting that quark_update_boottime(), quark_get_boottime() and quark_time_to_wallclock() are safe to call from any thread without synchronization, as an exception to the quark(7) queue-synchronization convention.

Merge order: that statement is only true once #393 merges — it routes all access to the process-wide quark.boottime/quark.hz through relaxed __atomic helpers (codegen-identical on x86-64/aarch64, builds on the centos7 gcc 4.8.5). Today the epoch is a plain u64, so concurrent UpdateBoottime/TimeToWallclock — as auditbeat does across two independent consumers in one process — is a data race. #393 needs to land before this PR.

@biscout42 biscout42 left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM; I would appreciate a second review from a person with more experience in the times we collect for quark events to verify the docs.

Comment thread docs/index.html
Comment thread quark_time_to_wallclock.3
Manpages for quark_update_boottime(3), quark_get_boottime(3) and
quark_time_to_wallclock(3), listed in quark(7), with the HTML docs
and README.md regenerated. The pages document which times are
expressed since boot, that btime comes from /proc/stat and moves on
clock steps, and two common ways of detecting a step.
The boottime epoch is process-wide, shared by every queue, and
auditbeat updates it from one thread while others translate
timestamps, which no caller-side lock can span. State explicitly that
quark_update_boottime(), quark_get_boottime() and
quark_time_to_wallclock() may be called from any thread without
synchronization, as an exception to the queue synchronization
convention in quark(7).

Only true once the boottime-atomics branch merges, which makes the
epoch access atomic.
The kprobe backend stamps times with a monotonic clock that does not
advance during suspend. quark_time_to_wallclock() applies unchanged,
but the result lags the wallclock by the total suspended time, exactly
as it did before 0.8. Spell this out in quark_time_to_wallclock(3) and
point QQ_MONOTONIC in quark_queue_open(3) at it, so kprobe users know
the boottime calls treat both backends the same and how to compensate
if they care about suspend.
Review feedback: make explicit which clock problem the epoch refresh
solves. Slewing adjusts the wallclock and the boot clock at the same
rate so the epoch never moves, only a step does.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants