From owner-cvs-src@FreeBSD.ORG Wed Jan 31 22:20:41 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 BE9A416A405; Wed, 31 Jan 2007 22:20:41 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (arm132.internetdsl.tpnet.pl [83.17.198.132]) by mx1.freebsd.org (Postfix) with ESMTP id 21A5A13C49D; Wed, 31 Jan 2007 22:20:41 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 23EE045CDA; Wed, 31 Jan 2007 23:20:40 +0100 (CET) Received: from localhost (154.81.datacomsa.pl [195.34.81.154]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 9B4F045681; Wed, 31 Jan 2007 23:20:32 +0100 (CET) Date: Wed, 31 Jan 2007 23:19:44 +0100 From: Pawel Jakub Dawidek To: John Baldwin Message-ID: <20070131221944.GD487@garage.freebsd.pl> References: <20070128202917.5B67916A5A6@hub.freebsd.org> <200701301636.38175.jhb@freebsd.org> <20070130233238.GB94650@garage.freebsd.pl> <200701311308.16810.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="a2FkP9tdjPU2nyhF" Content-Disposition: inline In-Reply-To: <200701311308.16810.jhb@freebsd.org> X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 7.0-CURRENT i386 User-Agent: mutt-ng/devel-r804 (FreeBSD) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-2.6 required=3.0 tests=BAYES_00 autolearn=ham version=3.0.4 Cc: Scott Long , src-committers@freebsd.org, cvs-src@freebsd.org, cvs-all@freebsd.org, arch@freebsd.org, Nate Lawson 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 22:20:41 -0000 --a2FkP9tdjPU2nyhF Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jan 31, 2007 at 01:08:14PM -0500, John Baldwin wrote: > [...] Anyways, maybe this=20 > issue will bubble up to someone's todo list at BSDCan to settle how to ha= ndle=20 > CPU's arriving and departing. One big thing that worries me is how to ha= ndle=20 > pinned and bound threads when a CPU goes away. Also, it may be more usef= ul=20 > to think of CPUs not as just present/not present, but more in terms of: >=20 > - not present > - present but offline > - present and online >=20 > And most code would really only care about offline/online events. We cou= ld=20 > maybe allow pinned and bound threads to still run on an offline CPU (and = the=20 > idlethread for that CPU of course) but require that there be no pinned bo= und=20 > threads to completely detach a CPU (in the case of systems with removable= =20 > CPUs). It would be useful to at least handle taking CPUs offline and the= n=20 > back online though. As a consumer of such functionality I'd like something like this: - I'd like to register myself as interested in receiving "CPU-online" and "CPU-offline" events. The EVENTHANDLER(9) KPI seems to be ok. When my registration is from a kernel module (all CPUs are already online), I'd like to still receive a fake CPU-online event for all of them. - When my CPU-online handler is called, I'd like to start my thread from there and be sure that CPU won't go offline before I return from the handler. It will be nice to be able to specify CPU ID I want to bind to in kthread_create(). This would save me from the kthread_create-sleep-wakeup dance. - When someone asks for a CPU to go offline, all CPU-offline handlers are called one by one and CPU will work (and stay online) until the last handler returns. - It'll be nice to get an error in return from sched_bind() return if CPU is going offline or is already offline. - Would be nice if there will be no need for the consumers to handle the boot CPU somehow specially. --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --a2FkP9tdjPU2nyhF Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFFwRYAForvXbEpPzQRApUxAJ9VgE0alhpkwP8dhX+0lNF+sZzX4gCeLrZ6 OFTwuTgWVa+ZA2DX1B6HDhE= =x1C6 -----END PGP SIGNATURE----- --a2FkP9tdjPU2nyhF--