From owner-cvs-src@FreeBSD.ORG Wed Jan 31 23:32:56 2007 Return-Path: X-Original-To: cvs-src@freebsd.org Delivered-To: cvs-src@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 81C3516A402 for ; Wed, 31 Jan 2007 23:32:56 +0000 (UTC) (envelope-from nate@root.org) Received: from root.org (root.org [67.118.192.226]) by mx1.freebsd.org (Postfix) with ESMTP id 65C9E13C47E for ; Wed, 31 Jan 2007 23:32:56 +0000 (UTC) (envelope-from nate@root.org) Received: (qmail 43496 invoked from network); 31 Jan 2007 23:32:42 -0000 Received: from adsl-67-119-74-222.dsl.sntc01.pacbell.net (HELO ?10.0.0.44?) (nate-mail@67.119.74.222) by root.org with ESMTPA; 31 Jan 2007 23:32:42 -0000 Message-ID: <45C1270C.1050308@root.org> Date: Wed, 31 Jan 2007 15:32:28 -0800 From: Nate Lawson User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: John Baldwin References: <20070128202917.5B67916A5A6@hub.freebsd.org> <200701301636.38175.jhb@freebsd.org> <20070130233238.GB94650@garage.freebsd.pl> <200701311308.16810.jhb@freebsd.org> In-Reply-To: <200701311308.16810.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Cc: Scott Long , src-committers@freebsd.org, Pawel Jakub Dawidek , cvs-src@freebsd.org, cvs-all@freebsd.org, arch@freebsd.org Subject: Re: cvs commit: src/sys/geom/eli g_eli.c X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jan 2007 23:32:56 -0000 John Baldwin wrote: > I wouldn't sell yourself so short actually. :) You're probably more competent > than you think. I'm not really an expert on SMP or schedulers either (I've > not had any formal training, and if you were to review some of my earlier SMP > stuff it shows), but ended up working on it because it needed to be done. > Most of what I've learned is by just working on stuff. Anyways, maybe this > issue will bubble up to someone's todo list at BSDCan to settle how to handle > CPU's arriving and departing. One big thing that worries me is how to handle > pinned and bound threads when a CPU goes away. Also, it may be more useful > to think of CPUs not as just present/not present, but more in terms of: > > - not present > - present but offline > - present and online > > And most code would really only care about offline/online events. We could > maybe allow pinned and bound threads to still run on an offline CPU (and the > idlethread for that CPU of course) but require that there be no pinned bound > threads to completely detach a CPU (in the case of systems with removable > CPUs). It would be useful to at least handle taking CPUs offline and then > back online though. I think this is a good design, assuming that all code that creates a thread and pins it are forced to register to receive events. That way you don't end up with a thread pinned and blocking the CPU going away. This capability will also be useful for suspend/resume on SMP since we need to stop CPUs and then restart them after resume. -- Nate