What is software interrupts in application?

[bluehive]

Hello all,
I have an a client/server based multi-threaded application. The server's CPU consumption goes up-and-down from 0.1% to 15% although everything i.e. n/w, disk I/O remains almost same. In 'top' output, I see that "%si" is in complete sync with CPU utilization.

Is there a way to get to know which software interrupts are making up this percentage of "si".

I found "/proc/softirq" but I could not found a rpm for that.

Thanks,
Vishal

[Rubberman]

Hello all,
I have an a client/server based multi-threaded application. The server's CPU consumption goes up-and-down from 0.1% to 15% although everything i.e. n/w, disk I/O remains almost same. In 'top' output, I see that "%si" is in complete sync with CPU utilization.

Is there a way to get to know which software interrupts are making up this percentage of "si".

I found "/proc/softirq" but I could not found a rpm for that.

Thanks,
Vishal

I think that threads use software interrupts on a timer to time-slice between threads. This requires a save/restore of the threads' stackframes, which is likely quite expensive in overhead terms. Multiple cores help (1 or more per thread) by allowing multiple threads to run without needing to push/pull stuff from cache or memory.

As for /proc/softirq and an rpm - there is no relationship. An rpm is a file to install software on the system. /proc contains information about the running system, such as processes, devices, running software, registered interrupts, etc. Since my CentOS/RHEL system only has /proc/irq and no /proc/softirq, I cannot say what is there on your system.

[bluehive]

Hi Rubberman,
Thanks for the reply. I understand that the probem may be side effect of thread scheduling but I doubt so. It's because this pattern is regular and application throughput is fairly constant.
I was thinking of getting a patch for "softirq" as an rpm?

Thanks again,
Blue

[Rubberman]

An rpm to patch softirq would be a kernel patch. It depends upon your distribution and kernel that it is using. I doubt that would be an issue here. A lot of the overhead, while appearing to be a software irq issue, may be due to the way the application and its use of threads is coded. There are too many factors to analyze at this level. Use of a good deterministic profiling tool, such as IBM/Rationional/Pure's Quantify, might help determine where the overhead is coming from.

Also, note that "top" only looks at performance in snapshots, and trying to take too fine-grained a view of what it is presenting is not good analytical technique. It is useful for detecting really bad resource consuming applications, and to monitor in a general way the health of the system - I use it myself for that all the time, keeping an instance of top running continuously. In any case, periodic use of 10-15% CPU is not, in my professional opinion, a matter of major concern. My xorg process gets worst than that occasionally when it performs some sort of "housekeeping" task.