[Bug 215836] [PATCH] sbin/dmesg: support new flag for watching messages

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=215836

--- Comment #5 from Mateusz Guzik <mjg at FreeBSD.org> ---
(In reply to joe from comment #4)

> I cannot simply go through syslog, as too much delay and overhead.

What delay and overhead do you have in mind here? Sure, reading output only
after it got processed by syslog is somewhat later then reading it "instantly",
but even with your patch you have worst-case 100ms delay. i.e., does not look
like it is a factor here. Also you already have syslog processing all this
data.

> 1. In researching "sys/kern/subr_log.c", I see it only accepts a single process watching (as you've kindly mentioned). Since the whole point of this file is centered around read-only operations; I feel it would be safe and fairly non-complex to support multiple processes performing open() and kevent() calls by switching to a linked list of "struct selinfo". Each waiting process may then utilize kevent() mechanisms; with additional changes to the mutex calls.

The problem is not with notifications but the buffer state not being per-file
object. That is, distinct open()s of the file doing reads steal each others
content. Thus allowing such opens would give rather surprising results. Fixing
this looks non-trivial (or rather, cumbersome and worth it given supposed
gains).

In principle perhaps someone would accept an "allow anyway" knob, but I'm not
convinced this is the way to go here.

> 2. Use the value of "kern.log_wakeups_per_second" to calculate a better sleep() call between loops.

With the current value of 5 this is 200ms. What latency do you expect to see
from syslog?

The standard model of operation is that you go to the kernel and let it wait
for stuff as it sees it. Periodic wakeups of an otherwise idle process, which
almost never has anything to do are a last resort. Similarly, the current in
the kernel should be reworked at some point, but at least it is not a
user-visible problem.

That said, my suggested way is:
1. configure syslog to log events you want to an unused tty (e.g. /dev/ttyvb)
2. use watch(8) (it requires the 'snp' kernel module) to stream events as they
show up
3. ... alternatively hack up a slightly nicer tool also using the snp module

This has a somewhat cost of reading a message, but I doubt it will be visible
in anything short of a microbenchmark. In the meantime, there is no thread
being woken up constantly when there are no events vast majority of the time.

-- 
You are receiving this mail because:
You are the assignee for the bug.