From owner-svn-src-all@FreeBSD.ORG Fri Feb 17 09:06:10 2012 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 12B10106566B; Fri, 17 Feb 2012 09:06:10 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id CE34F8FC21; Fri, 17 Feb 2012 09:06:09 +0000 (UTC) Received: from julian-mac.elischer.org (c-67-180-24-15.hsd1.ca.comcast.net [67.180.24.15]) (authenticated bits=0) by vps1.elischer.org (8.14.4/8.14.4) with ESMTP id q1H95tuV017826 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 17 Feb 2012 01:05:56 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <4F3E18CE.1010700@freebsd.org> Date: Fri, 17 Feb 2012 01:07:26 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.26) Gecko/20120129 Thunderbird/3.1.18 MIME-Version: 1.0 To: Pawel Jakub Dawidek References: <201202160511.q1G5BZNk099785@svn.freebsd.org> <20120216181210.K1423@besplex.bde.org> <4F3CC40D.4000307@freebsd.org> <4F3CC5C4.7020501@FreeBSD.org> <4F3CC8A5.3030107@FreeBSD.org> <20120216174758.GA64180@nargothrond.kdm.org> <20120217053341.R1256@besplex.bde.org> <20120217000846.GA7641@nargothrond.kdm.org> <4F3D9D03.6020507@FreeBSD.org> <9CB7ECE8-FF10-43BE-9EBD-16953BE3B193@xcllnt.net> <20120217085840.GC1358@garage.freebsd.pl> In-Reply-To: <20120217085840.GC1358@garage.freebsd.pl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 17 Feb 2012 12:24:34 +0000 Cc: marcel@freebsd.org, Eitan Adler , svn-src-all@freebsd.org, "Kenneth D. Merry" , Andriy Gapon , Marcel Moolenaar , src-committers@freebsd.org, Bruce Evans , svn-src-head@freebsd.org Subject: Re: svn commit: r231814 - in head/sys: kern sys X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 09:06:10 -0000 On 2/17/12 12:58 AM, Pawel Jakub Dawidek wrote: > On Thu, Feb 16, 2012 at 08:49:05PM -0800, Marcel Moolenaar wrote: >> On Feb 16, 2012, at 4:19 PM, Andriy Gapon wrote: >> >>> on 17/02/2012 02:08 Kenneth D. Merry said the following: >>> [snip] >>>>>> On Thu, Feb 16, 2012 at 11:13:09 +0200, Andriy Gapon wrote: >>> [snip] >>>>>>> For me personally the immediate benefits in the common situations >>>>>>> outweighed the >>>>>>> problems in the edge cases, although I still believe that we can get the >>>>>>> former >>>>>>> without sacrifices in the latter. >>> [snip] >>>> It sounds fine, but I don't have sufficient time to spend on this right >>>> now. So I can either back out the changes I mentioned above (assuming we >>>> get agreement from avg), or leave things as is. >>> I stick to what I wrote above and so chose the status quo. >>> The backout would make sense if it is immediately followed by commit of a better >>> solution. Unfortunately, a lack of time here too. >> I think we should lift above the immediate problem and allow for >> single- and multi-line messages that are atomically appended to >> the message buffer. Console output and propagation of messages >> outside of the kernel should all come out of the message buffer >> and preserving the atomicity of the messages. >> >> The message buffer does not have to be a chunk of memory that >> we circularly scribble to. It can be a per-cpu linked list of >> messages even. >> >> The advantage of thinking along these lines is that: >> 1. Console output can be made optional very easily, allowing >> us to implement quiet boots without loosing the ability >> to look at messages collected during boot. >> 2. Atomicity allows us to parse the messages reliably, which >> works very well in the embedded space where monitoring of >> kernel messages is common. >> 3. You can decouple writing into the message buffer from >> extracting messages out of the message buffer, allowing >> the low-level console to become just another channel to >> send messages to, rather than be fundamental for printf. >> 4. A linked list (for example) eliminates the problem of >> scribbling over old messages and possibly leaving partial >> output that gets misinterpreted. >> 5. A per-cpu message buffer eliminates serialization to >> guarantee atomcity and with timestamping can very easily >> be turned into a sequential log. >> 6. We haven't introduced complications (e.g. locking) to >> solve these problems and that make using printf in low- >> level code impossible. Thank trap handlers or interrupt >> handlers. > I agree with everything except for per-CPU buffers. I understand the > need for using printf in low-level code and it indeed complicates things. > The reason I don't like the idea of per-CPU buffers is that locking > would allow me to implement atomicity across multiple printfs. > For example I often use macros like this: > > #define G_MIRROR_DEBUG(lvl, ...) do { \ > if (g_mirror_debug>= (lvl)) { \ > printf("GEOM_MIRROR"); \ > if (g_mirror_debug> 0) \ > printf("[%u]", lvl); \ > printf(": "); \ > printf(__VA_ARGS__); \ > printf("\n"); \ > } \ > } while (0) > > And I'd like all the printfs to be committed as one message without > using some additional buffer first and then single printf. > With some kind of printf-lock we could use recursive locking to achieve > this. In your proposal I may run each printf on different CPU. > I could eventually use sched_pin() around all printfs, I guess. > This still doesn't cover the case when I'm preempted between my printfs, > so maybe I need critical section there? I don't expect printf should be > fast, so it might be ok. with locking your example could still be broken up because there is a lock per printf.. if you want them done together you really should print parts to a separate assembly buffer and then put it all out at once. I actually like the idea of pcpu buffers. witha single atomic sequence number being the only sychroniaation needed.