From owner-freebsd-hackers@FreeBSD.ORG Fri Feb 16 19:04:17 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A1D1B16A406 for ; Fri, 16 Feb 2007 19:04:17 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.ntplx.net (mail.ntplx.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id 5F23C13C478 for ; Fri, 16 Feb 2007 19:04:17 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.ntplx.net (8.14.0/8.14.0/NETPLEX) with ESMTP id l1GJ458n020177; Fri, 16 Feb 2007 14:04:05 -0500 (EST) X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.ntplx.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-3.0 (mail.ntplx.net [204.213.176.10]); Fri, 16 Feb 2007 14:04:05 -0500 (EST) Date: Fri, 16 Feb 2007 14:04:05 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: John Giacomoni In-Reply-To: <1959ECB1-61D4-4034-BB10-83D68DA01B13@colorado.edu> Message-ID: References: <368841.53689.qm@web32903.mail.mud.yahoo.com> <45CD31D3.8040106@ironport.com> <1959ECB1-61D4-4034-BB10-83D68DA01B13@colorado.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; delsp=yes; format=flowed Content-ID: Cc: freebsd-hackers@freebsd.org, Julian Elischer Subject: Re: pin/bind a pthread to a processor? (take 2) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Feb 2007 19:04:17 -0000 What you are trying to do is real-time work. You will need to place your thread(s) or process in the real-time class or priority range and modify the scheduler(s) if necessary to support RT. I'm not familiar with the schedulers, but I suspect most of your work should be spent on getting one of the schedulers (whichever can more easily support it) to operate correctly for RT threads and processes. RT is something that I found Solaris is pretty good at, at least with later versions of Solaris. You might investigate that if you can't get FreeBSD to operate efficiently/correctly for RT processing. We have been using Solaris for real-time simulation for many years now. I would love to be able to use FreeBSD as well, especially because we can embed it a lot easier than Solaris, but I don't think it's quite there yet. -- DE