From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 5 00:29:40 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from localhost.my.domain (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 741E316A407; Thu, 5 Oct 2006 00:29:40 +0000 (UTC) (envelope-from davidxu@freebsd.org) From: David Xu To: freebsd-hackers@freebsd.org Date: Thu, 5 Oct 2006 08:29:36 +0800 User-Agent: KMail/1.8.2 References: <20061004214040.GA6878@porthos.spock.org> In-Reply-To: <20061004214040.GA6878@porthos.spock.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200610050829.36266.davidxu@freebsd.org> Cc: Jonathan Chen Subject: Re: running code on all CPUs X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Oct 2006 00:29:40 -0000 On Thursday 05 October 2006 05:40, Jonathan Chen wrote: > Hello, > > I'm currently writing kernel code to use MCA (machine check architecture) > in order to detect things like ECC errors. As part of this, I need to run > code on all CPUs periodically to check some status registers. Where is the > best place to do this? It doesn't seem that I can use regular kernel > threads since I can't specify a CPU binding with that interface. I've > thought about hooking a function call to either the beginning of > idle_proc() or somewhere in mi_switch(), but neither solution seems optimal > since there are no guarantees when idle_proc() is ran and mi_switch() seems > like a really bad idea from a performance standpoint. Suggestions? > > Also, are there any locking pitfalls or other issues I should be aware of > when writing code to run in either idle_proc() or mi_switch()? > > -Jon AFAIK, you can use scheduler API, the sched_bind() moves current thread to a specific CPU, hope this helps. David Xu