From owner-freebsd-arch@freebsd.org Wed Feb 17 17:39:27 2016 Return-Path: Delivered-To: freebsd-arch@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 B8AD3AABAD8 for ; Wed, 17 Feb 2016 17:39:27 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id A781F1BF7 for ; Wed, 17 Feb 2016 17:39:27 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id A67F4AABAD5; Wed, 17 Feb 2016 17:39:27 +0000 (UTC) Delivered-To: arch@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 A6158AABAD0 for ; Wed, 17 Feb 2016 17:39:27 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.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 88B6C1BF6 for ; Wed, 17 Feb 2016 17:39:27 +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 bigwig.baldwin.cx (Postfix) with ESMTPSA id 25636B918; Wed, 17 Feb 2016 12:39:26 -0500 (EST) From: John Baldwin To: Konstantin Belousov Cc: arch@freebsd.org Subject: Re: Starting APs earlier during boot Date: Wed, 17 Feb 2016 09:00:26 -0800 Message-ID: <38395751.7hkq6XTlKk@ralph.baldwin.cx> User-Agent: KMail/4.14.3 (FreeBSD/10.2-STABLE; KDE/4.14.3; amd64; ; ) In-Reply-To: <20160217094241.GF91220@kib.kiev.ua> References: <1730061.8Ii36ORVKt@ralph.baldwin.cx> <20160217094241.GF91220@kib.kiev.ua> 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.2.7 (bigwig.baldwin.cx); Wed, 17 Feb 2016 12:39:26 -0500 (EST) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2016 17:39:27 -0000 On Wednesday, February 17, 2016 11:42:41 AM Konstantin Belousov wrote: > On Tue, Feb 16, 2016 at 12:50:22PM -0800, John Baldwin wrote: > > However, we can run a slightly simpler version of our scheduler before > > timers are working. In fact, sleep/wakeup work just fine fairly early (we > > allocate the necessary structures at SI_SUB_KMEM which is before the APs > > are even started). Once idle threads are created and ready we could in > > theory let the APs startup and run other threads. You just don't have working > > timeouts. OTOH, you can sort of simulate timeouts if you modify the scheduler > > to yield the CPU instead of blocking the thread for a sleep with a timeout. > > The effect would be for threads that do sleeps with a timeout to fall back to > > polling before timers are working. In practice, all of the early kernel > > threads use sleeps without timeouts when idle so this doesn't really matter. > I understand that timeouts can be somewhat simulated this way. > > But I do not quite understand how generic scheduling can work without > (timer) interrupts. Suppose that we have two threads 1 and 2 of the same > priority, both runnable, and due to some event thread 2 preempted thread > 1. If thread 2 just runs without calling the preempt functions like > msleep, what would guarentee that thread 1 eventually gets it CPU slice ? Nothing, but the only thread we have that does that during early startup is thread0 (which is what should be running as it is the one that makes progress to getting timers setup). Currently the sleep calls just always return which means if any thread gets on the CPU it never yields and is stuck forever. My changes make it so only a CPU bound thread is stuck forever, and we only have one such thread before timers are running: thread0. > E.g. there might be no interrupts set up yet, and idle thread on UP > gets on CPU, then the whole boot process could deadlock. The idle threads are special as they yield explicitly if there are any runnable threads on the run queues. -- John Baldwin