linux-kernel - Re: [PATCH] x86: skip delays during SMP initialization similar to Xen

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAJvTdKmv7_nSpR2283GjM1gjof=xDhmMzE9X5hf+UtRDwppFdw@mail.gmail.com>
Date:	Thu, 28 May 2015 22:16:35 -0400
From:	Len Brown <lenb@...nel.org>
To:	Ingo Molnar <mingo@...nel.org>
Cc:	Jan H. Schönherr <jschoenh@...zon.de>,
	Thomas Gleixner <tglx@...utronix.de>, X86 ML <x86@...nel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Anthony Liguori <aliguori@...zon.com>,
	Ingo Molnar <mingo@...hat.com>,
	"H. Peter Anvin" <hpa@...or.com>, Tim Deegan <tim@....org>,
	Gang Wei <gang.wei@...el.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [PATCH] x86: skip delays during SMP initialization similar to Xen

>> this time can be reduced by 7% (113 ms) by deleting announce_cpu()

While the KERN_DEBUG output is fast, accounce_cpu() uses KERN_INFO,
which goes to the (serial) console by default.

One would expect it to drain at about 10 bits/byte / 115200 baud = 87us/byte.
I measured some vanilla printk's via KERN_INFO on this server, and they ran
at 100us/byte.  I guess that isn't so far off -- an effective 100,000 baud...

announce_cpu() is actually 8 lines @ 112 bytes/line = 896 bytes, on this box.
@ 100usec/byte, that is 89ms -- about double your estimate of 50ms;
and closer to my original observation that deleting announce_cpu()
altogether saved 113ms.

I suppose somebody at 9600 baud would be less delighted -- 10x slower
would be 896 bytes * 10 bits/byte / 9600 = 933ms, yeas, almost a ful lsecond,
 just for announce_cpu() output.

So I guess the question is if announce_cpu() really needs to be KERN_INFO,
or if it can be KERN_DEBUG. I think that KERN_DEBUG is sufficient,
though if it were up to me, I'd delete it entirely.

That is because the success case prints this on the console already:

[    1.959675] x86: Booted up 4 nodes, 120 CPUs
[    1.965202] smpboot: Total of 120 processors activated (671148.72 BogoMIPS)

Success also prints the pretty announce_cpu() list in dmesg,
and can still do so if "debug" is on the cmdline...

But most importantly, the error case would trip output
in native_cpu_up(), due to this upstream patch:

commit feef1e8ecbadf24f8e6829c935df8683cabae41b
Author: Igor Mammedov <imammedo@...hat.com>
Date:   Thu Jun 5 15:42:44 2014 +0200

    x86/smpboot: Log error on secondary CPU wakeup failure at ERR level

    If system is running without debug level logging,
    it will not log error if do_boot_cpu() failed to
    wakeup AP. It may lead to silent AP bringup
    failures at boot time.
    Change message level to KERN_ERR to make error
    visible to user as it's done on other architectures.

    Signed-off-by: Igor Mammedov <imammedo@...hat.com>
    Acked-by: Toshi Kani <toshi.kani@...com>
    Cc: Thomas Gleixner <tglx@...utronix.de>
    Link: http://lkml.kernel.org/r/1401975765-22328-3-git-send-email-imammedo@redhat.com
    Signed-off-by: Ingo Molnar <mingo@...nel.org>

diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c
index 2988f69..ae2fd975 100644
--- a/arch/x86/kernel/smpboot.c
+++ b/arch/x86/kernel/smpboot.c
@@ -918,7 +918,7 @@ int native_cpu_up(unsigned int cpu, struct
task_struct *tidle)

        err = do_boot_cpu(apicid, cpu, tidle);
        if (err) {
-               pr_debug("do_boot_cpu failed %d\n", err);
+               pr_err("do_boot_cpu failed(%d) to wakeup CPU#%u\n", err, cpu);
                return -EIO;
        }

cheers,
Len Brown, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/