From owner-svn-src-all@freebsd.org Tue Jan 17 17:32:42 2017 Return-Path: Delivered-To: svn-src-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 898C5CB4089; Tue, 17 Jan 2017 17:32:42 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from mail.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 646F5156E; Tue, 17 Jan 2017 17:32:42 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from ralph.baldwin.cx (c-73-231-226-104.hsd1.ca.comcast.net [73.231.226.104]) by mail.baldwin.cx (Postfix) with ESMTPSA id 8307610A7DB; Tue, 17 Jan 2017 12:32:41 -0500 (EST) From: John Baldwin To: Bruce Evans Cc: Sean Bruno , src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r312205 - in head/sys: kern net Date: Tue, 17 Jan 2017 07:04:03 -0800 Message-ID: <2068311.SHO1HLFUnD@ralph.baldwin.cx> User-Agent: KMail/4.14.10 (FreeBSD/11.0-STABLE; KDE/4.14.10; amd64; ; ) In-Reply-To: <20170117113927.E1043@besplex.bde.org> References: <201701150050.v0F0oAU8055428@repo.freebsd.org> <30935285.ropjfVExpa@ralph.baldwin.cx> <20170117113927.E1043@besplex.bde.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mail.baldwin.cx); Tue, 17 Jan 2017 12:32:41 -0500 (EST) X-Virus-Scanned: clamav-milter 0.99.2 at mail.baldwin.cx X-Virus-Status: Clean X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2017 17:32:42 -0000 On Tuesday, January 17, 2017 12:02:49 PM Bruce Evans wrote: > On Mon, 16 Jan 2017, John Baldwin wrote: > > > On Sunday, January 15, 2017 12:50:10 AM Sean Bruno wrote: > >> ... > >> Log: > >> Fix hangs in a uniprocessor configuration (qemu, virtualbox, real hw). > >> > >> sys/net/iflib.c: > >> Add ctx to filter_info and don't skpi interrupt early on unless we're on an > >> SMP system > > > > On an SMP system with EARLY_AP_STARTUP (default on x86) this code should > > never see smp_started as false anyway, so these checks should likely just > > be conditional on EARLY_AP_STARTUP (since that option will eventually go > > away). > > Ifdefs on EARLY_AP_STARTUP give strange results for the UP case (at least > for SMP with 1 CPU). First, the ifdef in sys/kernel.h moves SI_SUB_SMP > from late to early, although the CPU initialization order has not changed > when there is only 1 CPU. Then everything that uses SI_SUB_SMP is > reordered, and bugs in the new order show up even in the UP case. Most of the things that used to use SI_SUB_SMP no longer do (there is now a SI_SUB_LAST that many of those things use). > sys/gtaskqueue.h uses a complicated combination of EARLY_AP_STARTUP and > SI_SUB ifdefs to try to get the order right. I think the last commit to > it helps for the UP case but harms for the SMP case (both for the > !EARLY_AP_STARTUP case). Its code is simpler for the EARLY_AP_STARTUP > case. In the !EARLY_AP_STARTUP case, it has to split up the initialization > to delay calculations depending on the number of CPUs until after SMP > has started. The last commit to it seems to have turned the split into > nonsense by removing the delay. But in the UP case, the split is not > really necessary and removing the delay should help. > > EARLY_AP_STARTUP works badly here. It doesn't give a much faster startup > for the early part of the boot. Then it gives a much slower boot by > hanging for almost a minute waiting for USB or something. Starting all > the CPUs early also unimproves debugging by interleaving the boot messages > a bit. I use colorized console messages (with the color indexed by the > CPU). This makes interleaved messages quite readable and gives interesting > patterns when multiple CPUs are running. The interleaving I am aware of is from USB which starts its own kthreads during attach directly rather than using config_intrhook like other drivers which do bus exploration later in boot (e.g. all the SCSI devices). I tried to describe this to Hans but will probably just come up with a patch to change USB to use config_intrhook which might help. -- John Baldwin