Unix Programming - poll issue

Author

poll issue

Ethan Yu

2005-04-14, 6:03 pm

I have a CPU occupancy problem on Linux platform.
The scenario is as follows:
I have an application, run it on solaris platform and
Linux platform, but the CPU occupancies of the process are
very different. On Solaris, the CPU occupancy is about 60%
and the CPU occupancy of user call is the same as system
call's from top info. But on Linux the CPU occupancy is about
90% and the CPU occupancy of system call is more than 70%.
In strace logs, I found that the CPU occupancy of system call
was mostly happened on poll function. This is different from
Solaris's.

Could somebody give me help?

Thanks.

Pascal Bourguignon

2005-04-14, 6:03 pm

"Ethan Yu" <ycy_76@163.net> writes:

> I have a CPU occupancy problem on Linux platform.
> The scenario is as follows:
> I have an application, run it on solaris platform and
> Linux platform, but the CPU occupancies of the process are
> very different. On Solaris, the CPU occupancy is about 60%
> and the CPU occupancy of user call is the same as system
> call's from top info. But on Linux the CPU occupancy is about
> 90% and the CPU occupancy of system call is more than 70%.
> In strace logs, I found that the CPU occupancy of system call
> was mostly happened on poll function. This is different from
> Solaris's.
>
> Could somebody give me help?

Perhaps you're calling poll(2) (or select(2)) with a timeout too
small, therefore the program is effectivelly doing polling instead of
waiting for events?

Try to increase the timeout (or use 0 to indicate infinite timeout).

--
__Pascal Bourguignon__ http://www.informatimago.com/
Our enemies are innovative and resourceful, and so are we. They never
stop thinking about new ways to harm our country and our people, and
neither do we. -- Georges W. Bush

James Antill

2005-04-16, 7:51 am

On Thu, 14 Apr 2005 17:38:00 +0200, Pascal Bourguignon wrote:

> "Ethan Yu" <ycy_76@163.net> writes:
>
>
> Perhaps you're calling poll(2) (or select(2)) with a timeout too
> small, therefore the program is effectivelly doing polling instead of
> waiting for events?

I've seen this before when people use a busy spin (Ie. timeout
immediately), Solaris/win32 seem to somehow act more how the people doing
this[1] believe it should. When I've seen it changing the timeout to 1
msec seems to give the "desired" behaviour on all platforms.

> Try to increase the timeout (or use 0 to indicate infinite timeout).

Note that passing 0 to poll()/select() does the exact opposite -- it
returns immediately (maybe you were thinking of passing a NULL timeout
pointer to select?)

[1] My personal feeling is that if you aren't passing a timeout for the
next time you _have_ to do something, your code is broken ... but that's
me.

--
James Antill -- james@and.org
Need an efficient and powerful string library for C?
http://www.and.org/vstr/