Many applications can achieve better performance when most processing occurs at user-level rather than kernel-level. To identify how an application is performing, enter the following command:
onload_stackdump lots | grep polls| Counter | Description |
|---|---|
k_polls
|
Number of times the socket event queue was polled from the kernel. |
u_polls
|
Number of times the socket event queue was polled from user space. |
periodic_polls
|
Number of times a periodic timer has polled for events. |
interrupt_polls
|
Number of times an interrupt polled for network events. |
deferred_polls
|
Number of times poll has been deferred to the stack lock holder. |
timeout_interrupt_polls
|
Number of times timeout interrupts polled for network events. |
$ onload_stackdump lots | grep poll k_polls: 673 u_polls: 41The output identifies many more k_polls than
u_polls indicating that the stack is operating mainly at
kernel-level and might not be achieving optimal performance. A possible cause is that
application logic is taking longer than EF_POLL_USEC.
Solution
Terminate the application and set the EF_POLL_USEC parameter to 100000. Restart the application and re-run onload_stackdump:
export EF_POLL_USEC=100000 onload_stackdump lots | grep polls$ onload_stackdump lots | grep polls k_polls: 673 u_polls: 1289The output identifies that the number of u_polls is far greater than the number of k_polls indicating that the stack is now operating mainly at user-level.
For more information see Spinning, Polling and Interrupts.