Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

SMP/dual (multi) core phase II



On Sun, May 06, 2007 at 09:47:08PM -0400, markw at mohawksoft.com wrote:
> > determined by Linux. This scales linearly on both single-core
> > CPUs and multicore CPUs. It scales almost, but not quite,
> > linearly on HyperThreading CPUs. you are saying
> 
> Please explain what you mean. "Hyperhreading" CPUs are multi-core CPUs,
> aren't they, or am I missing something?

Nope. HyperThreading CPUs are complex single CPUs with the
ability to run in two modes: one is a full capacity single core,
and the other is two lower-capacity cores which share
significant on-chip resources.

> SMP systems don't scale linearly, pretty close as long as there is no
> contention, but not linearly. I'm concerned about the resource contention
> on multi-core CPUs.

I just explained that for our workload, SMP systems scale
linearly -- at least to 8 x86 processors. Your workload may
vary, but a blanket statement such as the one above is simply
incorrect.

> >> Second, does anyone out there know if dual core processors can (as a
> >> matter of hardware and OS implementation) be used to run two different
> >> processes simultaneously rather than merely two different threads of a
> >> single process.
> >
> > Yes.
> 
> Are you sure?

Yes. That's why I said "Yes." and not "For our workload, that is
the case."

> > That is not the case. CPU cache is split between the processes,
> > but unless you have a program structure where the main loops
> > don't fit into cache, you are unlikely to see much impact.
> > Remember, you're running a multitasking OS anyway. Right?
> 
> Multi-core CPUs generally share an MMU between processors. When an OS (on
> 386 and higher CPU based operating systems) switch tasks, they also switch
> (if I recall correctly) the CR3 register to switch page descriptors or
> edit they page table map. If processors are sharing memory management
> units, running two different processes on two different processing cores
> should not be possible CPU, cache or not.

Multiway associative caches have been standard for years. While one MMU
is mapping pages into the cache with requests issued by both cores,
the cache controller is smart enough not to let one core eat all the
space recently used by the other one.

> This isn't bad if you have multi-threaded apps, but if you have an app
> that multi-tasks using fork(), you are SOL on multi-core, unless, of
> course, this is incorrect.

You are incorrect. Our workload multi-tasks via fork().

Since you don't seem to believe me, why don't you buy or borrow
a nice 2-CPU, 4-core system and test out your workload? It's not
that expensive in a desktop chassis.

-dsr-


-- 
.. .----. --   .-. . .- -.. .. -. --.   -.-- --- ..- .-.   -- .- .. .-.. .-.-.-   .-- .... ---   . .-.. ... .   .. ... ..--.. 
http://tao.merseine.nu/~dsr/eula.html is hereby incorporated by reference.

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.





BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org