From owner-freebsd-hackers@FreeBSD.ORG Mon Jan 31 15:29:13 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3889316A4CE for ; Mon, 31 Jan 2005 15:29:13 +0000 (GMT) Received: from mail.revolutionsp.com (ganymede.revolutionsp.com [64.246.0.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0881243D31 for ; Mon, 31 Jan 2005 15:29:13 +0000 (GMT) (envelope-from security@revolutionsp.com) Received: from mail.revolutionsp.com (localhost [127.0.0.1]) by mail.revolutionsp.com (Postfix) with ESMTP id 2C94815C96 for ; Mon, 31 Jan 2005 09:29:05 -0600 (CST) Received: from 81.84.175.77 (SquirrelMail authenticated user security@revolutionsp.com); by mail.revolutionsp.com with HTTP; Mon, 31 Jan 2005 09:29:05 -0600 (CST) Message-ID: <51596.81.84.175.77.1107185345.squirrel@81.84.175.77> In-Reply-To: <51581.81.84.175.77.1107185131.squirrel@81.84.175.77> References: <51547.81.84.175.77.1107182494.squirrel@81.84.175.77> <51581.81.84.175.77.1107185131.squirrel@81.84.175.77> Date: Mon, 31 Jan 2005 09:29:05 -0600 (CST) From: security@revolutionsp.com To: freebsd-hackers@freebsd.org User-Agent: SquirrelMail/1.4.3a X-Mailer: SquirrelMail/1.4.3a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: Re: Simple question about CPUs and processes X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2005 15:29:13 -0000 Hey, Thanks for the replies Robert and Ryan! That was insigthful. I didn't know about the BP and the shutdown thingy, always learning :-) >> On Mon, 31 Jan 2005 security@revolutionsp.com wrote: >> >>> I'd like some insight on the following; Me and a friend were discussing >>> tech stuff and he said that, when using dual (or more) CPU systems, it >>> is the hardware itself (and alone) choosing which CPU will execute this >>> or that process. >>> >>> But I think it is the OS kernel (FreeBSD in this case) and the SMP >>> implementation that decide this process should live in CPU0 or CPU1, ie >>> it's FreeBSD itself choosing on what CPU a process will reside in. >> >> This is basically the case on hardware supported by FreeBSD: the OS >> scheduler decides where to place processes in order, ideally, to >> maximize >> performance. The hardware will affect the performance, however, due to >> some systems supporting non-uniform access to chunks of memory depending >> on the CPU the code runs on, the contents of the cache, etc. Often, the >> job of the OS scheduler isn't simply to decide on fair or desirable run >> orders based on priority, but where best to run the process/thread based >> on where it's run recently, clusters of related CPUs, etc. These issues >> are becoming more important on i386-based systems with the advent of >> hyper-threading, dual-core chips, amd64 NUMA, etc. In the end, though, >> the decision (good or bad) will be made by the OS. >> >> There is two exceptions regarding execution: >> >> - The hardware may be involved in deciding which CPU will receive >> interrupts -- for example, it may round-robin deliver timer interrupts >> to CPUs to attempt to help manage interrupt load. This will cause an >> interrupt handler to run on the CPU selected by the hardware, at which >> point the OS can decide whether it wants to process the interrupt on >> that CPU, or forward it to another for processing. >> >> - There are some activities that must be performed on specific >> processors. >> For example, the boot necessarily starts out on the boot processor >> (BP). >> It turns out that many Intel or Intel-like systems get quite unhappy >> if >> system shutdown is initiated from a non-boot processor, so FreeBSD >> also >> arranges for the boot processor to issue the power down call into ACPI >> on platforms running ACPI. The hardware isn't choosing where to run >> this code per se, but if you pick the wrong one the hardware won't >> like >> you :-). >> >> Hope this is helpful, >> >> Robert N M Watson >> >> > >