Date: Tue, 17 Jan 2017 12:02:49 +1100 (EST) From: Bruce Evans <brde@optusnet.com.au> To: John Baldwin <jhb@freebsd.org> Cc: Sean Bruno <sbruno@freebsd.org>, src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r312205 - in head/sys: kern net Message-ID: <20170117113927.E1043@besplex.bde.org> In-Reply-To: <30935285.ropjfVExpa@ralph.baldwin.cx> References: <201701150050.v0F0oAU8055428@repo.freebsd.org> <30935285.ropjfVExpa@ralph.baldwin.cx>
next in thread | previous in thread | raw e-mail | index | archive | help
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. 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. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20170117113927.E1043>