How to ... assign process to particular processor?

[Piotr Smerda]

Hi.
Short description of my problem.
I have a HP rp4440-8 with 4 processors and 16GB RAM. I want to compress some files on this system . I want to use bzip2 or gzip and I want (e.g.) to assign first gzip-process to processor 1, second gzip-process to processor 3 and third gzip-process to processor 4.
I have no idea how to assign particular process to one specific processor. Is there any external command or something that I can use in sh script to assign process to processor? And is there a tool to read status of processors (idle, process name and so on)?

--
Regards
Piotr

[James R. Ferguson]

Hi:

If you are serious about this kind of thing, you should look at PRM (Process Resource Manager):

http://www.hp.com/products1/unix/operating/docs/prm.overview.pdf

Regards!

...JRF...

[Ivan Ferreira]

I think that you first have to create a processor set with the psrset command, then bind a process to that set. See man psrset for more info.

[Tomek Gryszkiewicz]

But why to do it? OS will assign the processes better..

[Ajitkumar Rane]

Piotr,

The HP-UX OS will take care of the the processes being assigned to multiple processors. Its only if you have Process Resource Manager, you can assign a particular process to a Processer

Rgds,

Ajit

[Sundar_7]

Process Resource Manager (PRM) with Processor Sets (PSET) is the way to go. You need to license PRM and PSET comes for free.

[Ivan Ferreira]

You can also run the command with nice -n 19 gzip file to reduce the priority of the command. You can use renice to modify the priority of a running process.

[Bill Hassell]

top will show you usage by processor. The assigning of a specific process to a single processor is called processor affinity but as many sysadmins have discovered (after creating a special program to do the assignments), there is no measureable difference in performance.

The reason is that there is no overhead in switching a process to run on one processor or another. All processors have access to all of memory and once an I/O is complete, the next available processor is used to run the next instructions. Exactly the same steps are needed when the same processor is used over and over again, thus no performance gain.

If you want to play with processor affinity, look at the man pages for mpctl(2) which is a program interface and also man mpsched. See also:

http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=181384

[Hein van den Heuvel]

Forget about psets. Too restrictive and too much work.

Just use mpsched.

Bill wrote: "The reason is that there is no overhead in switching a process to run on one processor or another. All processors have access to all of memory and once an I/O is complete, the next available processor is used to run the next instructions. Exactly the same steps are needed when the same processor is used over and over again, thus no performance gain."

Hogwash! Oops, did I say that?
I meant "I respectfully beg to differ".
Processor cache state and address space mapping registers are becoming more and more important as memory speed lags more and more compared to CPU speeds.
With every cpu switch the process looses it's cache context potentially slowing it down significantly.
Of course for this to be noticable one must have a cpu and memory intense application. As soon as significant IOs are involved, it becomes a moot point. ZIP is borderline. In several tests I did I found it to be measurably faster to bind to cpu's, but you need full control over the environment. You must have little or no contention for that cpu, or it will hurt more than in helps.

In general the HPUX scheduler does a fine job of trying to keep a process on a cpu, to more succesful it is at doign that on its own. then less effect plaing with mpsched (or psets) is going to have.


Just an other opinion,
Cheers,
Hein.

[Bill Hassell]

And I agree with Hein. That's the reason I used a mixed program (zip = CPU + I/O) as an example. In a purely CPU bound program, the processor state will not be interrupted unless a context switch is necessary. And as Hein mentioned, HP-UX does a good job in keeping proceses running on the same CPU. So for a bunch of CPU-intensive processes (no I/O) running at the same time (and enough free processors), using psets or letting HP-UX manage things will see little or no difference. Only when there are not enough processors to run all the processes at the same time will a context switch occur.

Similarly, a process like zip will be spending most of it's time waiting on I/O (unless the CPU is very slow, perhaps less than 200 Mhz). So the TLB load and processor cache advantage will be minimal compared to the time spent waiting for an I/O to complete.