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.

I'm still unclear on the distinction you are using.

>
>> 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.

SMP is fairly well understood here. That's not what I'm asking about.
There are a lot of fairly common situations where SMP does not scale
linearly, specifically, where it usually competes with I/O and memory
bandwidth. OS lock contention is another area where SMP doesn't scale
linearly.

multi-core CPUs have even more false parallelism.

>
>> >> 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.

What happens when an instruction requests a memory address (data or
instruction) that is not in cache, and the current CR3 or page map is
wrong with regard to the processes? How does the processor get the memory?


>
>> 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().

I'm not sure I can buy that just yet.
>
> 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.

I'm just doing the research right now. I have a single CPU multi-core
system at my current contract and it does not behave the same way as my
SMP systems in my lab.



-- 
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