Date: Sat, 07 Jan 2017 18:16:05 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-bugs@FreeBSD.org Subject: [Bug 215836] [PATCH] sbin/dmesg: support new flag for watching messages Message-ID: <bug-215836-8-KSgbVnccD6@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-215836-8@https.bugs.freebsd.org/bugzilla/> References: <bug-215836-8@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=215836 --- Comment #5 from Mateusz Guzik <mjg@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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-215836-8-KSgbVnccD6>