From owner-freebsd-hackers@freebsd.org Fri Jul 1 06:43:15 2016 Return-Path: Delivered-To: freebsd-hackers@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 BDA19B8D200 for ; Fri, 1 Jul 2016 06:43:15 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id AD8102FC5 for ; Fri, 1 Jul 2016 06:43:15 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from comporellon.tachypleus.net (75-101-50-44.static.sonic.net [75.101.50.44]) (authenticated bits=0) by c.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id u616hDru011676 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Thu, 30 Jun 2016 23:43:13 -0700 To: "freebsd-hackers@freebsd.org" From: Nathan Whitehorn Subject: Review request: sparse CPU ID maps Message-ID: <57761101.3030101@freebsd.org> Date: Thu, 30 Jun 2016 23:43:13 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Sonic-CAuth: UmFuZG9tSVZrCPE4NuFGbfScBqjTtPOSI2oGxsQxaxxK7xSzOhuBwgId/x1La5+YlSZlroCsaYFVWsYpGW2858LqEcIQA++Uy50d6xYfu/A= X-Sonic-ID: C;gIxaFVc/5hG5PZtMTlz00w== M;NGScFVc/5hG5PZtMTlz00w== X-Spam-Flag: No X-Sonic-Spam-Details: 0.0/5.0 by cerberusd X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2016 06:43:15 -0000 I have been working on fixing PR 210106 (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=210106) and have run into the fact that several pieces of the kernel, notably parts of subr_taskqueue.c, require that CPU IDs be dense in the range [0, mp_ncpus), which the kernel does not guarantee, for example in the case of CPUs with hyperthreading in which the threading is disabled. This is leading to hangs in late boot in -CURRENT. I've prepared the following patch, which fixes PR 210106, but I would like a few more eyeballs on it before committing it. It fixes most of the bogus uses of mp_ncpus in the kernel, but not all: doing grep -R '< mp_ncpus' /sys | wc -l gives 52 remaining instances of loops in [0, mp_ncpus) or [1, mp_ncpus), most or all of which should instead be CPU_FOREACH(), but none of which I feel comfortable changing (36 are in ARM code for hardware I don't have access to). The patch lives here: http://people.freebsd.org/~nwhitehorn/sparse_cpu_ids.diff -Nathan