Operating System - HP-UX
1753797 Members
7711 Online
108799 Solutions
New Discussion юеВ

Re: 'poll' system call consuming 100% CPU on HPUX Itanium

 
wini008
Occasional Contributor

'poll' system call consuming 100% CPU on HPUX Itanium

The 'poll' system call on HPUX B.11.31 Itanium consumes 100% CPU if called repeatedly(timeout of 5000ms)with more than 100+ poll fd structures. The same works fine(less than 1% CPU) in  HPUX B.11.23 Itanium and all the other Linux flavours. 
The issue gets resolved if a 'nanosleep()' of 1 nanosecond is introduced just before the 'poll' system call. 
This indicates that there exists a problem in 'poll' implemenation on HPUX B.11.31. Suspecting some of the fields/parameters inside 'poll' are not getting set/reset by kernel on calling repeatedly(timeout of 5000ms). Introducing a dummy sleep('nanosleep() of 1 nanosecond) between successive 'poll' (just before calling 'poll()') resolves the problem.

Is it a bug in HPUX B.11.31?

3 REPLIES 3
Stan_M
HPE Pro

Re: 'poll' system call consuming 100% CPU on HPUX Itanium

I guess the problem is in the "... repeatedly ...". So what do the poll() calls return? Maybe you can share the relevant piece of code?

I work for HPE
Dennis Handly
Acclaimed Contributor

Re: 'poll' system call consuming 100% CPU on HP-UX Integrity

It's always a good idea to have a sleep in a loop when polling or looping so that other processes can get the CPU.

But you would think with a timeout of 5000 ms, that would be the "sleep".  Is poll(2) returning with an error right away?

wini008
Occasional Contributor

Re: 'poll' system call consuming 100% CPU on HPUX Itanium

It's a server program. It monitors the client requests through 'poll()'. Here the '...repeatedly...' refers to "number of times poll() invokation increases as the number of client connection increases". I cannot think of any issue with "...repeatedly..." logic, the reason being is as follows:

1. The same logic works fine(less than 1% CPU) in HPUX B.11.23 Itanium and all the other unix systems(Linux, AIX, Solaries, FreeBSD). 
2. The same logic works fine if I use 'select()' instead of 'poll()'
3. How does setting 'nanosleep()' of just 1 nano second before 'poll()' resolves the problem.

Why do we need to introduce the sleep() explicitly, in looping/polling as the last parameter of the 'poll()' i.e timeout does not work?