From owner-freebsd-bugs@freebsd.org Sat Jan 7 18:16:05 2017 Return-Path: Delivered-To: freebsd-bugs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3C59ACA4E9D for ; Sat, 7 Jan 2017 18:16:05 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2147C1B6A for ; Sat, 7 Jan 2017 18:16:05 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v07IG4J9082514 for ; Sat, 7 Jan 2017 18:16:05 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-bugs@FreeBSD.org Subject: [Bug 215836] [PATCH] sbin/dmesg: support new flag for watching messages Date: Sat, 07 Jan 2017 18:16:05 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: patch X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: mjg@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-bugs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jan 2017 18:16:05 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D215836 --- Comment #5 from Mateusz Guzik --- (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.=