Date: Mon, 31 Jan 2005 09:29:05 -0600 (CST) From: security@revolutionsp.com To: freebsd-hackers@freebsd.org Subject: Re: Simple question about CPUs and processes 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> <Pine.NEB.3.96L.1050131145326.35704I-100000@fledge.watson.org> <51581.81.84.175.77.1107185131.squirrel@81.84.175.77>
next in thread | previous in thread | raw e-mail | index | archive | help
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 >> >> > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?51596.81.84.175.77.1107185345.squirrel>