From owner-freebsd-hackers@freebsd.org Sat Apr 21 18:35:09 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 D8E3CFB9089 for ; Sat, 21 Apr 2018 18:35:08 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: from mail-io0-f169.google.com (mail-io0-f169.google.com [209.85.223.169]) (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 77CF473111 for ; Sat, 21 Apr 2018 18:35:08 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: by mail-io0-f169.google.com with SMTP id t23-v6so1082143ioc.10 for ; Sat, 21 Apr 2018 11:35:08 -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=jl+Tlj47tp+MnyfZynkL0y7w6yJb3PgRKcWfSix8gzQ=; b=oMY3LK/CHKE1WQkpxCuZQFMQHBQgWHGe3FQWpUnphPzbNrwfIyE9gkUgYMPNmch8aI OEDD1MZIgjNlT6NH/BW65/cZshBR2gWOHTCk7kayvN9V5SelSrIMcHQ0dY4Ihbv5fhhl Zo1yAITfjUKIn8VAC6vU50WRkHUrlYS1+EirsJa7YDdn8A7usIEqtUsUMgikslkQ7v8i LCSKt+nDeHKOufkwsYH47es5ES2bh7hUyWY9unnrURoP7Kwh0uOst4P33rYyWqXKMxoL DbRvu0lgxtG/6+/tIZYk6xnm9xIKysdTII6id2NQURRFafrTrwMFs+HymNDs5aPlVy6K Zn4g== X-Gm-Message-State: ALQs6tCa9NQ89554oQN5OrJl6Yrpg/vnOUzUCi4dbXwG5jCEz+3pLAT6 Vje0/EFICp8PV+qjWW8Vqr0zZMzV X-Google-Smtp-Source: AIpwx49nHDl16XTB5iDR9xHnEj3UqSyhLHONmhbI1/09mEMzP0ThKsi7x6fPogZBJQj5gpt+y36Y3g== X-Received: by 2002:a6b:b7c6:: with SMTP id h189-v6mr14541865iof.94.1524333830503; Sat, 21 Apr 2018 11:03:50 -0700 (PDT) Received: from mail-io0-f182.google.com (mail-io0-f182.google.com. [209.85.223.182]) by smtp.gmail.com with ESMTPSA id x189-v6sm1164780ite.5.2018.04.21.11.03.50 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 21 Apr 2018 11:03:50 -0700 (PDT) Received: by mail-io0-f182.google.com with SMTP id f3-v6so13943874iob.13 for ; Sat, 21 Apr 2018 11:03:50 -0700 (PDT) X-Received: by 2002:a6b:da04:: with SMTP id x4-v6mr6427996iob.19.1524333829913; Sat, 21 Apr 2018 11:03:49 -0700 (PDT) MIME-Version: 1.0 Reply-To: cem@freebsd.org Received: by 2002:a02:224d:0:0:0:0:0 with HTTP; Sat, 21 Apr 2018 11:03:49 -0700 (PDT) In-Reply-To: References: <01000162df15f856-1e5d2641-2a72-4250-8d8e-adcd47bc5db4-000000@email.amazonses.com> <20180419204405.GE6887@kib.kiev.ua> <20180419214550.GF6887@kib.kiev.ua> <01000162e58a4670-66a9983e-c3ef-493a-a60f-c477645b5100-000000@email.amazonses.com> From: Conrad Meyer Date: Sat, 21 Apr 2018 11:03:49 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: RFC: Hiding per-CPU kernel output behind bootverbose To: Warner Losh Cc: Colin Percival , "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: Sat, 21 Apr 2018 18:35:09 -0000 On Sat, Apr 21, 2018 at 10:02 AM, Warner Losh wrote: > On Fri, Apr 20, 2018 at 6:11 PM, Colin Percival > wrote: >> Would it be sufficient for debugging purposes if I change the !bootverbose >> case from printing many lines of >> >> SMP: AP CPU #N Launched! >> >> to instead have a single >> >> SMP: Launching AP CPUs: 86 73 111 21 8 77 100 28 57 42 10 60 87 88 41 113 >> 36 >> 19 72 46 92 52 24 81 90 3 107 96 9 14 80 118 29 121 62 74 56 55 1 12 63 18 >> 67 >> 13 45 102 33 94 69 68 93 83 48 31 30 32 51 89 71 78 64 84 123 61 40 47 37 >> 22 >> 54 101 38 4 97 44 17 109 104 5 85 43 2 99 39 65 95 53 58 66 91 125 23 115 >> 16 >> 35 79 112 103 82 7 75 11 6 98 15 126 127 20 70 34 105 27 50 116 120 49 25 >> 108 >> 106 122 117 114 26 110 59 76 124 119 >> >> ? (With each AP printing its number as it reaches the appropriate point?) >> >> This yields almost the same gain as silencing the launch messages >> completely, >> while still allowing you to see each CPU announcing itself. > > > The trouble is that you've got N CPUs that are doing output at the same > time. You'll need to synchronize somehow. And how do you know that the last > one is done? Especailly if one of the CPUs doesn't start.. > > It looks great in theory, but I'm not sure how you'd make it work in > practice. Yeah. You could pare down the number of characters per-AP substantially. Something like: SMP: Launching APs: 2 3 4 ... It sounds like EC2 is redrawing on every character emitted, scrolling or not. So the additional line breaks shouldn't hurt. Best, Conrad