Dual Xeon - Spread 99.9 to 2 Procs?
 

I have a Dual Xeon machine, RH9... 4 processors list because of the hyperthreading, but I have a problem... I've got some powerful software that uses 99.9% of one of these 4 processors.

Is there a way (software?) to spread that out to take 50% of 2 of the 4? I can't find any documentation or help on this anywhere... I actually have a feeling the software would like to use more, lets say 60% on each of 2... to make 120% of one processor, which is causing some slowness.


Thanks!

If the program does not take advantage of threading
or use fork() to distribute load then no there's not
really anything you can do.

I found this. How would it work for me?


affinity.c :

/*
* Simple command-line tool to set affinity
* Robert Love, 20020311
*/
#include <stdio.h>
#include <stdlib.h>
#include <sched.h>
#include "affinity.h"

int main(int argc, char * argv[])
{
unsigned long new_mask;
unsigned long cur_mask;
unsigned int len = sizeof(new_mask);
pid_t pid;
if (argc != 3) {
printf(" usage: %s <pid> <cpu_mask>\n", argv[0]);
return -1;
}
pid = atol(argv[1]);
sscanf(argv[2], "%08lx", &new_mask);
if (sched_getaffinity(pid, len, &cur_mask) < 0) {
printf("error: could not get pid %d's affinity.\n", pid);
return -1;
}
printf(" pid %d's old affinity: %08lx\n", pid, cur_mask);
if (sched_setaffinity(pid, len, &new_mask)) {
printf("error: could not set pid %d's affinity.\n", pid);
return -1;
}
if (sched_getaffinity(pid, len, &cur_mask) < 0) {
printf("error: could not get pid %d's affinity.\n", pid);
return -1;
}
printf(" pid %d's new affinity: %08lx\n", pid, cur_mask);
return 0;
}

affinity.h :

#define _AFFINITY_H
#include <sched.h>
#include <unistd.h>
#include <linux/unistd.h>
/*
* provide the proper syscall information if our libc is not yet updated.
* It is suggested you check your kernel to make sure these are right for
* your architecture.
*/
#if defined(__i386__)
#define __NR_sched_setaffinity241
#define __NR_sched_getaffinity242
#endif
_syscall3(int, sched_setaffinity, pid_t, pid, unsigned int, len,
unsigned long *, user_mask_ptr)
_syscall3(int, sched_getaffinity, pid_t, pid, unsigned int, len,
unsigned long *, user_mask_ptr)

Compile this program:

gcc affinity.c -o affinity

Then run it like so:

affinity PID 1 (stick to CPU 0)
affinity PID 2 (stick to CPU 1)
affinity PID 3 (stick to both cpu)

EG: affinity 14932 1

If you have more processors, like 4, then affinity PID 5 would assign it to all processors (let the linux scheduler do its work) ...

I'm using this with kernel 2.5, and I believe it only works with 2.5, unless you patch your 2.4 kernel..

It really wouldn't do anything for you.
It lets you choose which process runs
on which processor. This doesn't help
you unless there are a lot of processes
running on that one CPU and for some
reason not using the others.

The speed of SMP systems aren't equal to
the sum of their clocks they can only run
processes in parallel and there-by appear
faster by taking advantage of concurrency.
No process can run faster than the clock
speed of of the processors in the system.
e.g. I have 2 1.2GHz processors the fastest
any process can run is at the performance
of a 1.2GHz processor. My computer *seems*
like it is faster because I can be running two
processes at once.

Also if you are running a 2.5.x kernel
upgrade to 2.6-test-9 or what ever the
latest is.

shot in the dark
 

is smp processing enabled in the kernel?