* Borislav Petkov <bp@xxxxxxxxx> wrote:
> On Wed, Sep 25, 2013 at 08:29:36PM +0200, Ingo Molnar wrote:
> > Indeed, that should be fixed.
>
> Ok, how does a right alighment look like:
>
> [ 0.072399] smpboot: Booting Node 0, Processors #1 #2 #3 #4 #5 #6 #7 OK
> [ 0.617005] smpboot: Booting Node 1, Processors #8 #9 #10 #11 #12 #13 #14 #15 OK
> [ 1.230005] smpboot: Booting Node 2, Processors #16 #17 #18 #19 #20 #21 #22 #23 OK
> [ 1.835005] smpboot: Booting Node 3, Processors #24 #25 #26 #27 #28 #29 #30 #31 OK
> [ 2.437005] smpboot: Booting Node 4, Processors #32 #33 #34 #35 #36 #37 #38 #39 OK
> [ 3.053005] smpboot: Booting Node 5, Processors #40 #41 #42 #43 #44 #45 #46 #47 OK
> [ 3.657009] smpboot: Booting Node 6, Processors #48 #49 #50 #51 #52 #53 #54 #55 OK
> [ 4.256005] smpboot: Booting Node 7, Processors #56 #57 #58 #59 #60 #61 #62 #63 OK
>
> ?
Looks cool. The perfectionist in me would love to skip CPU0's space so
that we get:
[ 0.072399] smpboot: Booting Node 0, Processors #1 #2 #3 #4 #5 #6 #7 OK
[ 0.617005] smpboot: Booting Node 1, Processors #8 #9 #10 #11 #12 #13 #14 #15 OK
[ 1.230005] smpboot: Booting Node 2, Processors #16 #17 #18 #19 #20 #21 #22 #23 OK
[ 1.835005] smpboot: Booting Node 3, Processors #24 #25 #26 #27 #28 #29 #30 #31 OK
[ 2.437005] smpboot: Booting Node 4, Processors #32 #33 #34 #35 #36 #37 #38 #39 OK
Pretty please? :-)
> With lockdep butting in-between it is still readable:
>
> [ 0.063330] SMP alternatives: lockdep: fixing up alternatives
> [ 0.064032] smpboot: Booting Node 0, Processors #1
> [ 0.141231] SMP alternatives: lockdep: fixing up alternatives
> [ 0.142007] #2
> [ 0.230210] SMP alternatives: lockdep: fixing up alternatives
> [ 0.231007] #3
> [ 0.307237] SMP alternatives: lockdep: fixing up alternatives
> [ 0.308007] #4
> [ 0.384231] SMP alternatives: lockdep: fixing up alternatives
> [ 0.385006] #5
> [ 0.468237] SMP alternatives: lockdep: fixing up alternatives
> [ 0.469007] #6
> [ 0.545230] SMP alternatives: lockdep: fixing up alternatives
> [ 0.546006] #7 OK
> [ 0.626323] Brought up 8 CPUs
> [ 0.627004] smpboot: Total of 8 processors activated (64217.00 BogoMIPS)
Hm, I realize that this was a nice test for the printout robustness, but
could you please also remove the alternatives message in another patch?
That message was cool and interesting back in the days when we wrote
lockdep ('hey, look ma, it really works!!'), but there hasn't been any
breakage in that area for a long time and it definitely does not deserve
one line of log spam per CPU! Especially if it messes up such a nice CPU
bootup table.
> I admit the digits calculation is a bit clumsy but I didn't want to do
> any log_10 crazy jumps through hoops and besides, it should be faster
> this way:
> - pr_cont(" #%4d%s", cpu, cpu == max_cpu_present ? " OK\n" : "");
> + num_digits = 1 + 1 * (cpu > 9) + 1 * (cpu > 99);
> +
> + pr_cont("%*s#%d", 4 - num_digits, " ", cpu);
> +
> + if (cpu == num_present_cpus() - 1)
> + pr_cont(" OK\n");
So how about taking log10(num_possible_cpus()) as the width of the
printout? (If it wraps out of the screen on 4K CPU systems then those
lucky people can resize their terminals or so.)
There's absolutely no speed consideration here, and people do keep staring
at the CPU bootup printout frequently. A small helper function can
construct a fixed-width entry into a string, which can be printed using %s.
Width only has to be calculated once:
static int num_digits(val)
{
int digits = 0;
while (val) {
val /= 10;
digits++;
}
return digits;
}
...
width = num_digits(num_possible_cpus());
...
And the beauty of it is that small, slow systems will naturally spend a
few cycles less time in num_digits() than large, fast systems.
(and I hope you learned the lesson about sending improvement patches
against long-bitrotten code, as the new x86 CPU bootup printout format
code maintainer!)
Thanks,
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-tip-commits" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
|