percpu: use KERN_CONT in pcpu_dump_alloc_info()
Subsystems (2)
Tejun Heo
maintainerPATCH 1/1 percpu: use KERN_CONT in pcpu_dump_alloc_info()
Quoted 1 line
From
cb129820f1e6ccf309510f4eb28df45cb0742005Mon Sep 17 00:00:00 2001
From: Tejun Heo <[email protected]>
Date: Thu, 29 Mar 2012 09:45:58 -0700
pcpu_dump_alloc_info() was printing continued lines without KERN_CONT. Use it.
---
Committed to percpu/for-3.4-fixes.
Thanks.
mm/percpu.c | 10 +++++----- 1 files changed, 5 insertions(+), 5 deletions(-)
mm/percpu.c +5 -5
@@ -1132,20 +1132,20 @@ static void pcpu_dump_alloc_info(const char *lvl,for (alloc_end += gi->nr_units / upa; alloc < alloc_end; alloc++) {if (!(alloc % apl)) { -printk ("\n" ); +printk (KERN_CONT "\n" );printk ("%spcpu-alloc: " , lvl); } -printk ("[%0*d] " , group_width, group); +printk (KERN_CONT "[%0*d] " , group_width, group);for (unit_end += upa; unit < unit_end; unit++)if (gi->cpu_map[unit] !=NR_CPUS ) -printk ("%0*d " , cpu_width, +printk (KERN_CONT "%0*d " , cpu_width, gi->cpu_map[unit]);else -printk ("%s " , empty_str); +printk (KERN_CONT "%s " , empty_str); } } -printk ("\n" ); +printk (KERN_CONT "\n" ); }/**
Signature · 1 line
1.7.7.3
Quoted 35 lines · Tejun Heo
Quoted 1 line
From
cb129820f1e6ccf309510f4eb28df45cb0742005Mon Sep 17 00:00:00 2001From: Tejun Heo <[email protected]>
Date: Thu, 29 Mar 2012 09:45:58 -0700
pcpu_dump_alloc_info()was printing continued lines withoutKERN_CONT. Use it.Signed-off-by Tejun Heo <[email protected]>Reported-by Kay Sievers <[email protected]>---
Committed to percpu/for-3.4-fixes.Thanks.
mm/percpu.c | 10 +++++----- 1 files changed, 5 insertions(+), 5 deletions(-)mm/percpu.c +2
-3@@ -1132,20 +1132,20 @@ static void pcpu_dump_alloc_info(const char *lvl,for (alloc_end += gi->nr_units / upa; alloc < alloc_end; alloc++) {if (!(alloc % apl)) { -printk ("\n" ); +printk (KERN_CONT "\n" );printk ("%spcpu-alloc: " , lvl); } -printk ("[%0*d] " , group_width, group); +printk (KERN_CONT "[%0*d] " , group_width, group);for (unit_end += upa; unit < unit_end; unit++)if (gi->cpu_map[unit] !=NR_CPUS ) - printk("%0*d ", cpu_width,
mm/percpu.c static void pcpu_dump_alloc_info(const char *lvl, · line 1149
Quoted 10 lines
mm/percpu.c +3
-2+printk (KERN_CONT "%0*d " , cpu_width, gi->cpu_map[unit]); else - printk("%s ", empty_str); + printk(KERN_CONT "%s ", empty_str); } } -printk ("\n" ); +printk (KERN_CONT "\n" ); }
Perhaps it's better to try to print lines
in fewer printks? Maybe use a line buffer?
The first line could be newline terminated.
"if (alloc)" tests for the individual newlines could be added. Why aren't the group widths on separate lines?
All of the cpu_widths are on the same line as the parent group even if that exceeds apl. Is that what's desired?
Tejun Heo
maintainerHello, Joe.
Quoted 2 lines · Joe Perches
Perhaps it's better to try to print lines
in fewer printks? Maybe use a line buffer?
What practical difference would that make?
Quoted 5 lines
The first line could be newline terminated.
"if (alloc)" tests for the individual newlines could be added. Why aren't the group widths on separate lines?
All of thecpu_widthsare on the same line as the parent group even if that exceeds apl. Is that what's desired?
I frankly don't remember. I wanted something easy on the eye during the development to verify the config results and it worked well enough for me. If you can simplify it, please go ahead and submit a patch.
Thanks.
Signature · 1 line
tejun
Quoted 1 line · Tejun Heo
Hello, Joe.
Hello Tejun.
Quoted 4 lines · Joe Perches
Quoted 2 lines
Perhaps it's better to try to print lines
in fewer printks? Maybe use a line buffer?What practical difference would that make?
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...
Tejun Heo
maintainerHello,
Quoted 5 lines · Joe Perches
It'd be just for avoidance of any other possible
interleaving from other threads.It's an
__initfunction 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?
Thanks.
Signature · 1 line
tejun
Quoted 11 lines · Tejun Heo
Quoted 5 lines · Joe Perches
It'd be just for avoidance of any other possible
interleaving from other threads.It's an
__initfunction 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.
Quoted 5 lines
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 one.
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.
Kay
Quoted 4 lines · Kay Sievers
The kernel's
printk()uses a static scratch buffer of 1024 chars. The prototype for theprintk()with facility and structure support I have, does a bit better and more reliable 'buffered IO' than the current one.
Can you send me a link to your code please?