SV: SV: SV: Multiple cpu?

[Eric H]

On Wed, 18 Sep 2002, Anders Andersson, IT wrote:

> Hmm, now I feel stupid but I have to ask.
> Whats the differense between instances and child processes?

Well, a lot of these terms mean just about the same thing. A child process
would be another instance of the application, but the sense I was using
"instance" was starting two copies of the application myself rather than
starting one and having it fork off children.

> You all probably figured out my level of expertice  =(
> but this is something I relly need to understand.
> My guess from the begining was thats with 2 cpu MS would be
> able to scan faster. But know Im not sure If I should spend the
> extra money.
> Does 2 cpu demands extra config or will it handle it by it self?

If you have a process running which is not multithreaded then the most it
can do is hog one CPU in a multiprocessor system. This would leave the
other processor(s) either idle or the scheduler will shove any other
processes that might be running over to the idle CPU(s).

If you are running a single threaded application then you can benefit from
running another instance of it on a dual CPU system and sometimes even
more than two instances due to IO blocking, scheduling, CPU utilization
and the demands of other processes all working out perhaps in your favor,
perhaps not. It depends on a lot of things us mere mortals won't ever
understand thoroughly, so we just try it and see if it make money.

If you are running a multithreaded process then the scheduler can migrate
individual threads of that process to other CPUs that might be present and
available in the system. But only certain types of applications can
benefit from multithreading and I sort of expect that MailScanner isn't
one of them because it seems pretty straightforward and linear, grab a
message, scan it, modify it and stash it. In fact, I think maybe a
majority of applications would not benefit from writing them in a
multithreaded model because you've got to have concrete reasons for
wanting to thread rather than it just sounding good to the sales lizards.

For example, several years ago I was messing around with Bochs, a really
neat i386 emulator in C++, which has since been GPLed. I was running
Windows 95 in Bochs on a RedHat 4.2 system with dual CPUs, on the 2.0.x
kernels which weren't all that great at SMP at the time, but it worked
marvelously well. Bochs was not multithreaded so it just hogged one
processor and left the other one free to run all the other processes on my
system. Something like the Seti at Home or the DES key searching
distributed projects would benefit from threading, forking off a bunch of
threads to be migrated/scheduled on whatever CPU is available at any given
time.

I haven't paid much attention to the SMP and threading issues in Linux for
a while because, uh, it just works, but I think that when a process
creates a thread it's just calling the clone or vfork system call a little
differently than spawning children and the resulting thread looks just
like any other process and has its own PID in the process table. There're
other things in there too, like I think threads can signal each other and
do other magic stuff.

Like Oddball the tank commander in "Kelly's Heros" said when asked why he
wasn't helping with maintenance, "Oh, man, I just ride in 'em. I don't
know what makes 'em work".

Eric