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=3D215836 --- 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 "instant= ly", but even with your patch you have worst-case 100ms delay. i.e., does not lo= ok 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 p= rocess 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 keve= nt() calls by switching to a linked list of "struct selinfo". Each waiting = process may then utilize kevent() mechanisms; with additional changes to th= e mutex calls. The problem is not with notifications but the buffer state not being per-fi= le object. That is, distinct open()s of the file doing reads steal each others content. Thus allowing such opens would give rather surprising results. Fix= ing 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 n= ot convinced this is the way to go here. > 2. Use the value of "kern.log_wakeups_per_second" to calculate a better s= leep() 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, whi= ch 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/ttyv= b) 2. use watch(8) (it requires the 'snp' kernel module) to stream events as t= hey 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 visib= le 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 tim= e. --=20 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>