Processes / CPU

[Roro_2]

Hello,

Our customer has an rp3440 server running HPUX 11i v1 , Oracle and banking application.
the server conatains one dual core CPU module 800 MHZ ( cpu 0 and CPU 1 ).
The "top" utility was showing processes running on both CPUs and some processes were shitting from one CPU to the other.
1- How can we let the process run on one CPU only?
2-Could we split the process load on both CPUs? A kind of load balancing the process load. Instead of 70% CPU usage on 1 CPU, we could obtain 35% on 2CPUs or so.
3-If we run 2 processes or instances, could we configure it such as each process run on a different CPU uniquely?
4- which utility permits the administrator to know the CPU usage (percentage ) of all processes on each CPU.

Thanks and Regards

Roger

[Sunny Jaisinghani]

Use GlancePlus for CPU usage monitoring.

For more details "man glance"

[Sharma Sanjeev]

Hi Roger

You can use PRM ( Process Resource Manager ) to resources like CPU, Memory etc

Regards
Sanjeev

[Matti_Kurkela · Accepted solution]

1) This is called "setting CPU affinity". You could write a small program that uses the mpctl() system call to change the settings.

For an example code, see this thread:

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

In all modern OSs, the process scheduler usually "knows" about the cost associated with moving a process from one CPU to another and automatically does whatever needed to perform the maximum amount of useful work.

2) You probably have one process that needs to do a large portion of the work. If the process is not programmed to use multiple threads, it cannot use more than 1 CPU core at a time.

Multiple threads offer benefit only if the workload is parallelizable. If the work is sequential in nature, splitting it into multiple threads may not be helpful: if thread 2 needs to wait until thread 1 has completed its work, having multiple threads only adds management overhead.

In this case, it is more efficient to let the process run on one CPU whenever possible to maximize the benefit gained from the CPU caches. Forcing the system to move a workload like this from one CPU to another and back to balance the loads would just increase management overhead with no benefit.

3) You can, but it might reduce total performance rather than increase it because it limits the number of options available to the OS's process scheduler.

4) As Sunny said, the optional (non-free) Glance product can do something like that.

MK

[Roro_2]

Hi,

Thanks a lot for your support .

Roger

[Bill Hassell]

> 1- How can we let the process run on one CPU only?

This is a misunderstanding of what happens when a process runs on a particular CPU. There is no overhead at all in 'shifting' from one CPU to another. Each time a process makes a call to the HP-UX kernel (ie, for I/O or a system call) the kernel will then return control to the program by setting the program counter and registers for first available processor. This happens for every context switch -- which can happen hundreds of times per second. Nothing is transferred from one CPU to another during these switches so there is no overhead. I assume that your question relates to performance issues -- very unlikely that PRM will help at all.

> 2-Could we split the process load on both CPUs?

Unless you can rewrite the program, there is no way to split the load. Your program executes one instruction and then another. Your program would have to be rewritten into separate sections (threads) that can run at the same time (and therefore on different CPUs).

> 3-If we run 2 processes or instances, could we configure it such as each process run on a different CPU uniquely?

While you can do this with considerable effort, most sites that do this report slower performance compared to letting HP-UX assign the processors.

> 4- which utility permits the administrator to know the CPU usage (percentage ) of all processes on each CPU.

Glance is an extra cost product that will give you all the details you would every need. To sort all the processes by CPU usage, you can use this command:

UNIX95=1 ps -e -o pcpu,args | sort -rn | head -20

This will show the top 20 processes that are consuming CPU time. Note that in your top utility, are the load averages larger than 1.0?

[Matti_Kurkela]

>> 1- How can we let the process run on one CPU only?

> This is a misunderstanding of what happens when a process runs on a particular CPU. There is no overhead at all in 'shifting' from one CPU to another.

I beg to differ: it is a case of a sure L1 cache miss vs. a pretty good chance of a L1 cache hit. The L1 caches are separate for each core in PA-RISC dual-core CPUs (and further split to Dcache and Icache, with 768 kB of each per core). The L2 cache is shared between cores.

When a process is running on the same CPU core as recently before, there is a good chance that at least some of the necessary data and instructions are still available in the L1 cache of that core. If everything is available in the L1 cache, the CPU core can resume running that process immediately, without waiting for anything.

If a process context is switched to another CPU core that has not run this process in the recent past, that core needs to fetch everything from the L2 cache before it can actually start doing useful work. That takes a few extra clock cycles. In a computer with two single-core CPUs, the instructions and data might have to be fetched all the way from RAM, which would take yet more time.

If the process is continuously flipped back and forth between the cores, both cores will likely have the process's next instructions in their caches. At that point, there's still a matter of write operations.

When the process writes some data into memory when running on core A, that core must signal to any other cores something like: "I just wrote into memory address X; if you have it cached, consider that part of the cache stale as of now." As far as I know, this is part of the Deep Magic of SMP-capable processor design, and I don't claim to understand it all. But I understand this signaling usually happens at the hardware level, so even the OS programmer normally does not need to worry about it.

Ultimately, it is not a case of "shifting the processes between CPU cores must be minimized at any cost": it's more like "try to keep them on the same cores as before if reasonably practical". I think most modern OSs already do this automatically.

MK

[Dennis Handly]

>Matti: it is a case of a sure L1 cache miss vs. a pretty good chance of a L1 cache hit.

Yes, I mentioned this penalty before:
http://forums.itrc.hp.com/service/forums/questionanswer.do?threadId=1369696