From owner-svn-src-all@FreeBSD.ORG Fri Feb 17 09:22:05 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 723B3106564A; Fri, 17 Feb 2012 09:22:05 +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 9BCBA8FC0A; Fri, 17 Feb 2012 09:22:03 +0000 (UTC) Received: from localhost (89-73-195-149.dynamic.chello.pl [89.73.195.149]) by mail.dawidek.net (Postfix) with ESMTPSA id 04FFC9A6; Fri, 17 Feb 2012 10:22:00 +0100 (CET) Date: Fri, 17 Feb 2012 10:20:42 +0100 From: Pawel Jakub Dawidek To: Julian Elischer Message-ID: <20120217092038.GD1358@garage.freebsd.pl> References: <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> <4F3E18CE.1010700@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Ycz6tD7Th1CMF4v7" Content-Disposition: inline In-Reply-To: <4F3E18CE.1010700@freebsd.org> 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:24:46 +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:22:05 -0000 --Ycz6tD7Th1CMF4v7 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Feb 17, 2012 at 01:07:26AM -0800, Julian Elischer wrote: > On 2/17/12 12:58 AM, Pawel Jakub Dawidek wrote: > > I agree with everything except for per-CPU buffers. I understand the > > need for using printf in low-level code and it indeed complicates thing= s. > > 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 > with locking your example could still be broken up because there is a > lock per printf.. >=20 > if you want them done together you really should print parts to a > separate assembly buffer and then put it all out at once. Not really. I was thinking about recursive printf-lock that is used internally by printf, but can also be used by printfs consumers, eg. mtx_lock(&printf_lock); printf("first thing "); printf("second thing"); mtx_unlock(&printf_lock); Again, printf internally is using printf_lock too. > I actually like the idea of pcpu buffers. witha single atomic sequence=20 > number being the only > sychroniaation needed. Maybe I'm over engineering here, but... If we store in the thread structure two things: your counter and information if the last message stored by this thread had \n at the end or not, we could reuse the same counter for the next message by this thread if the previous message had no \n. This way my macro will work with per-CPU lists and preemption. I'd still need sched_pin() though. --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://tupytaj.pl --Ycz6tD7Th1CMF4v7 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk8+G+YACgkQForvXbEpPzRu0QCfccoGdkD7ugHjp2Qfy6Cyv7jZ JS0An0qm+acifBdtyLSQBrYlP+mTNtps =u2sa -----END PGP SIGNATURE----- --Ycz6tD7Th1CMF4v7--