Bug #1081
closed100% CPU utilization with suricata 2.0 beta2+
Description
Commmit 98e4a14f6d59fe8928fd6e2af3d9c3e8b42d00bf (af-packet: update packet reading loop logic)
breaks suricata in afpacket mode (with workers).
Every worker thread is stuck at 100%.
Reverting this commit makes CPU utilization return to usual levels.
Apparently it seems at least the new check logic introduced by that commit
is buggy:
if (h.h2->tp_status & (TP_STATUS_KERNEL|TP_STATUS_USER_BUSY))actually becomes
if (h.h2->tp_status & TP_STATUS_USER_BUSY)because TP_STATUS_KERNEL is defined as 0.
Updated by Eric Leblond almost 11 years ago
Hello Alessandro.
Thanks for this bug report.
Can you try https://github.com/regit/suricata/tree/bug1081 to see if it fixes the issue for you. On my setup this is patch lower CPU usage to a correct level (even if I did not have 100% CPU usage without the patch).
Updated by Alessandro Guido almost 11 years ago
Eric Leblond wrote:
Can you try https://github.com/regit/suricata/tree/bug1081 to see if it fixes the issue for you. On my setup this is patch lower CPU usage to a correct level (even if I did not have 100% CPU usage without the patch).
Had a similar fix already running on my system:
if (h.h2->tp_status == TP_STATUS_KERNEL || h.h2->tp_status & TP_STATUS_USER_BUSY)running on my system and it seem to work fine.
Updated by Alessandro Guido almost 11 years ago
Fine here means "no more all CPUs stuck at 100%", I cannot judge the correctness of the change in the semantics of the code.
Updated by Eric Leblond almost 11 years ago
Thanks a lot Alessandro. The solution to try was the one I wanted to implement.
Updated by Eric Leblond almost 11 years ago
- Status changed from New to Closed
- Assignee set to Eric Leblond
Updated by Victor Julien almost 11 years ago
- Target version set to 2.0rc1
- % Done changed from 0 to 100