svn commit: r231814 - in head/sys: kern sys

Pawel Jakub Dawidek pjd at FreeBSD.org
Fri Feb 17 09:22:05 UTC 2012


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 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.

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 
> 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.

-- 
Pawel Jakub Dawidek                       http://www.wheelsystems.com
FreeBSD committer                         http://www.FreeBSD.org
Am I Evil? Yes, I Am!                     http://tupytaj.pl
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/svn-src-head/attachments/20120217/d77ca0cf/attachment.pgp


More information about the svn-src-head mailing list