[lkml]   [2012]   [Apr]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] percpu: use KERN_CONT in pcpu_dump_alloc_info()
On Thu, Mar 29, 2012 at 22:11, Tejun Heo <> wrote:
> On Thu, Mar 29, 2012 at 1:06 PM, Joe Perches <> wrote:
>> It'd be just for avoidance of any other possible
>> interleaving from other threads.
>> It's an __init function so that's not too likely,
>> but if it every happens...
> Ah, okay.  Forgot about that.  Yeah, the kernel is single threaded at
> that point, so it shouldn't matter. The code is rather complex so
> something simpler would be nice, I agree.
> Another thing is that we seem to have structured logging coming our
> way and maybe userspace can deal with racing continuing printks? Not
> sure how different streams could be distinguished tho. Maybe the
> printing task can be used to group them? Kay, is this something
> structured logging would solve?

The kernel's printk() uses a static scratch buffer of 1024 chars. The
prototype for the printk() with facility and structure support I have,
does a bit better and more reliable 'buffered IO' than the current

If interleaved printk messages are still a problem, we could allocate
a per-cpu scratch buffer and all continuation lines which stay on the
same CPU would share the same buffer before it is committed to the
global log buffer.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2012-04-01 15:33    [W:0.037 / U:1.456 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site