From owner-freebsd-hackers@freebsd.org Thu Apr 19 21:37:59 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A75E7FA4A22 for ; Thu, 19 Apr 2018 21:37:59 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: from mail-it0-f44.google.com (mail-it0-f44.google.com [209.85.214.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3B97C8854B for ; Thu, 19 Apr 2018 21:37:59 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: by mail-it0-f44.google.com with SMTP id h143-v6so178449ita.4 for ; Thu, 19 Apr 2018 14:37:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc; bh=ncCqr+ULadv3U4ezh7iuwercsfN5x+KUOJOxx9cQSBk=; b=ohttD8BnAmyk6cIln2xvRJJMWa8ksxl6F3ob+Qjnj0sn0nWOwrjUfu/qfGjFmyY3bB +nU8IKQso6qGobyNIzLj03GZovv/vE6vA6ZyOz8rOAMq2AcpqvkZX8i8g9VFUBGm6S0Y TPiA5wXZYs/B/tHWwP1YG0pMuzsUMg3Z+vAhAeIAZAKKpG6BZ4gN01Ut3wDt5CAJsIwQ QkEjJ7VdXySVtXB4WJN86jTgG/JqRbrKpRzl6Vqa2nd5N0bZTTE6FkVbInZn7do+TQSu azY66bzzuEzIa6rEziaQYOhhZAwSlwVZhsu7Lc2i/0AQCF+XPRfwj83nXRWdtdxxzarY SWDQ== X-Gm-Message-State: ALQs6tCGluePbGikVjXh4e+ppDAKlMbwTZD/fnoWtrYtW8Ya7BekMWQB N6pXD8eaNGDzW6aHYSrJ3ouK5GNE X-Google-Smtp-Source: AIpwx4+yJ+dBOvqiyZM7Lhn9odMBwtcI3wJQr/Xzoth2zS3332bGHE6UqJyCnbdtzwDglc0CuXbxEg== X-Received: by 2002:a24:b548:: with SMTP id j8-v6mr481070iti.146.1524173878246; Thu, 19 Apr 2018 14:37:58 -0700 (PDT) Received: from mail-it0-f42.google.com (mail-it0-f42.google.com. [209.85.214.42]) by smtp.gmail.com with ESMTPSA id i12-v6sm35917itb.7.2018.04.19.14.37.57 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 19 Apr 2018 14:37:58 -0700 (PDT) Received: by mail-it0-f42.google.com with SMTP id 85-v6so157675iti.4 for ; Thu, 19 Apr 2018 14:37:57 -0700 (PDT) X-Received: by 2002:a24:b103:: with SMTP id o3-v6mr507764itf.46.1524173877183; Thu, 19 Apr 2018 14:37:57 -0700 (PDT) MIME-Version: 1.0 Reply-To: cem@freebsd.org Received: by 2002:a02:224d:0:0:0:0:0 with HTTP; Thu, 19 Apr 2018 14:37:56 -0700 (PDT) In-Reply-To: <20180419204405.GE6887@kib.kiev.ua> References: <01000162df15f856-1e5d2641-2a72-4250-8d8e-adcd47bc5db4-000000@email.amazonses.com> <20180419204405.GE6887@kib.kiev.ua> From: Conrad Meyer Date: Thu, 19 Apr 2018 14:37:56 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: RFC: Hiding per-CPU kernel output behind bootverbose To: Konstantin Belousov , Colin Percival Cc: "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2018 21:38:00 -0000 On Thu, Apr 19, 2018 at 1:44 PM, Konstantin Belousov wrote: > On Thu, Apr 19, 2018 at 06:06:21PM +0000, Colin Percival wrote: >> On large systems (e.g., EC2's x1e.32xlarge instance type, with 128 vCPUs) >> the boot time console output contains a large number of lines of the forms >> >> SMP: AP CPU #N Launched! >> cpuN: on acpi0 >> estN: on cpuN >> >> Having 128 almost-identical lines of output doesn't seem very useful, and >> it actually has a nontrivial impact on the time spent booting. >> >> Does anyone mind if I hide these by default, having them only show up if >> boot verbosity is requested? +1. For the device attaches, perhaps it makes sense to add a device 'spammy' flag, and set it for per-CPU devices like cpuN or estN. Then the generic attach code can choose whether to print spammy attaches based on bootverbose. dmesg for device attaches seems mostly redundant with devinfo(8) for persistent devices like ACPI CPU and est(4). > The 'CPU XX Launched' messages are very useful for initial diagnostic > of the SMP startup failures. You need to enable bootverbose to see the > hang details, but for initial hint they are required. Unfortunately, AP > startup hangs occur too often to pretend that this can be delegated to > very specific circumstances. Really? I don't know that I've ever seen an AP startup hang. How often do they occur? Best, Conrad