# basic SMP question

## Jake

Someone on another forum said programs not built for SMP will always be stuck running on the first CPU. Is this true?

----------

## dvc5

SMP scheduling is handled by the kernel and is transparent to the program. I have a dual proc box at home that runs the simplest of programs across both processors.

----------

## Jake

That's what I thought, thanks.

----------

## ewan.paton

aparantly you can use bind to hold them on a specific cpu, an example of this i heard was the HT logical processor being used for database indexes and the real one for serving

----------

## Crg

 *ewan.paton wrote:*   

> aparantly you can use bind to hold them on a specific cpu, an example of this i heard was the HT logical processor being used for database indexes and the real one for serving

 

Don't really see binding to one "proc" being that useful on a HT processor as I think the cache is shared.

On a proper multiple processor box, binding apps to one proc (hard affinity) can increase performance slightly by optimising cache performance by stopping the process bouncing around cpus.

With the later linux kernel schedulers, though, such as the (0)1 scheduler it naturally tries to keep processors running on the cpu it was running on last (soft affinity), so it'd be very rare you'd want/need hard affinity.

 *jake wrote:*   

> Someone on another forum said programs not built for SMP will always be stuck running on the first CPU. Is this true?

 

You often (pretty always) have multiple processes running, and a process will be run on whatever cpu is available.Last edited by Crg on Mon Apr 26, 2004 6:28 pm; edited 1 time in total

----------

## ewan.paton

 *Crg wrote:*   

> 
> 
> actually it was Jake who wrote
> 
>  *ewan.paton wrote:*   Someone on another forum said programs not built for SMP will always be stuck running on the first CPU. Is this true? 
> ...

 

yeh i was reading about the proccesor affinity a couple of days ago, the db example was one some one mentioned to me and i put the two together, i assumed it was a good way of hardware renicing since the real proc is always suposed to get priority

since the cpu load on my system is 1%,1%,2% and 1% i dont think i need to bother about such things but unless needed for hotswaping on my next rig but its just nice to know its possible

----------

## Crg

 *ewan.paton wrote:*   

> actually it was Jake who wrote

 

Heh, yeah sorry about that messed up the quote.  :Smile: 

 *ewan.paton wrote:*   

> yeh i was reading about the proccesor affinity a couple of days ago, the db example was one some one mentioned to me and i put the two together, i assumed it was a good way of hardware renicing since the real proc is always suposed to get priority

 

That's possible.  Haven't really looked at how HT is handled by the scheduler.

----------

## spamspam

 *Crg wrote:*   

> 
> 
> With the later linux kernel schedulers, though, such as the (0)1 scheduler it naturally tries to keep processors running on the cpu it was running on last (soft affinity), so it'd be very rare you'd want/need hard affinity.
> 
> 

 

Here's one for you though:

We have a dual-CPU Athlon MP box that's used for image processing. There's enough cooling for most uses, but every few weeks we run a script that puts both CPUs and the 4 drive RAID-5 array at near 100% usage for 4-6 hours at a time. On warm days after about 2 hours the Heatsinks and Case get heat-soaked and the system shuts down (starting with one of the drives getting punted from the RAID). 

I tried only running one thread of the script so that it only ran one CPU, but that just extended it to about 3 hours before heat soak. Right now I have it set up to pause for a few seconds here and there in the inner loops. That keeps the temperatures down, but makes it take a very long time (going on 18 hours now and it's only 3/4 done).  

What I'd like to be able to do is run one thread, but alternate it back and forth between the CPUs. The utility "taskset" is allegedly the one that does this, but it's not installed and I can't figure out what package it's in.

What package is "taskset" in?

----------

## theDreamer

 *spamspam wrote:*   

>  *Crg wrote:*   
> 
> With the later linux kernel schedulers, though, such as the (0)1 scheduler it naturally tries to keep processors running on the cpu it was running on last (soft affinity), so it'd be very rare you'd want/need hard affinity.
> 
>  
> ...

 

I'm guessing you already know it , but just in case - the package called "schedutils"

----------

## Unther

However, unless the program is built for SMP, it will only run on one CPU at a time. The kernel can't parallelise the binarys (If I remember my HPC course rightly).

----------

## theDreamer

 *Unther wrote:*   

> However, unless the program is built for SMP, it will only run on one CPU at a time. The kernel can't parallelise the binarys (If I remember my HPC course rightly).

 

For the sake of general understanding:

The SMP kernel can execute different context on each processor.

If you have an heavy application that uses multi-threading the kernel will balance the threads between the different CPUs.

In the extreme case of the entire machine is running one heavy application which is single threaded, the kernel will assign almost an entire CPU and the rest of the system processes and services will run on the other.

Meaning, in worst case you have an almost dedicated processor for specific heavy thread (minimal interruptions) and everage cases the load will be balanced between the CPUs (multithreading).

----------

