From owner-svn-src-head@FreeBSD.ORG Fri Feb 17 09:00:02 2012 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6DD841065670; Fri, 17 Feb 2012 09:00:02 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mail.dawidek.net (60.wheelsystems.com [83.12.187.60]) by mx1.freebsd.org (Postfix) with ESMTP id 86D7C8FC13; Fri, 17 Feb 2012 09:00:01 +0000 (UTC) Received: from localhost (89-73-195-149.dynamic.chello.pl [89.73.195.149]) by mail.dawidek.net (Postfix) with ESMTPSA id 40BEC987; Fri, 17 Feb 2012 09:59:59 +0100 (CET) Date: Fri, 17 Feb 2012 09:58:41 +0100 From: Pawel Jakub Dawidek To: Marcel Moolenaar Message-ID: <20120217085840.GC1358@garage.freebsd.pl> 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> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="4ZLFUWh1odzi/v6L" Content-Disposition: inline In-Reply-To: <9CB7ECE8-FF10-43BE-9EBD-16953BE3B193@xcllnt.net> X-OS: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) X-Mailman-Approved-At: Fri, 17 Feb 2012 12:25:38 +0000 Cc: marcel@freebsd.org, Eitan Adler , svn-src-all@freebsd.org, "Kenneth D. Merry" , Andriy Gapon , src-committers@freebsd.org, Bruce Evans , svn-src-head@freebsd.org, Julian Elischer Subject: Re: svn commit: r231814 - in head/sys: kern sys X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 09:00:02 -0000 --4ZLFUWh1odzi/v6L Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Feb 16, 2012 at 08:49:05PM -0800, Marcel Moolenaar wrote: >=20 > On Feb 16, 2012, at 4:19 PM, Andriy Gapon wrote: >=20 > > 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= =20 > >>>>> outweighed the > >>>>> problems in the edge cases, although I still believe that we can ge= t the=20 > >>>>> 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. > >=20 > > 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. >=20 > 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. >=20 > 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. >=20 > 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 >=3D (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. --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://tupytaj.pl --4ZLFUWh1odzi/v6L Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk8+FsAACgkQForvXbEpPzQcJACgiaK7w82zbqkIwkPBI7ON3H0U jFcAoO0InQnDuQVaZLSGvqrX6jE28OLo =NhlN -----END PGP SIGNATURE----- --4ZLFUWh1odzi/v6L--