<div dir="ltr">Thanks a lot for the thorough explanation.<div>I really appreciate it.</div><div><br></div><div></div><div><div>From the above explanation, it means that, bro is expecting to be continued soon after the suspend call to tackle subtle race cases as you mentioned and there&#39;s no rest in between(suspend &amp; continue) which can stabilize the CPU load(basically it polls for it to be continued again). I hope it cleared my understanding of how suspend/continue_processing() calls works.</div></div><div><br></div><div>My use case is I want bro not to process any packets from any source(netmap pipe or libpcap) until I somehow sends a signal for bro to be continued. The use case is achieved even now but at a higher cost of CPU being loaded. </div><div><font color="#6fa8dc"><br></font></div><div><font color="#6fa8dc">&gt;&gt; if you want to make a GitHub issue for that enhancement (also may help if you provide more explanation of your use-case and the importance of this to it).</font></div><div><font color="#000000">Okay...</font></div><div><font color="#6fa8dc"><br></font></div><div>Thanks a lot again !!</div><div><br></div><div>Regards,</div><div>Nabil</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, May 29, 2020 at 10:12 PM Jon Siwek &lt;<a href="mailto:jsiwek@corelight.com">jsiwek@corelight.com</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Thu, May 28, 2020 at 9:55 PM Nabil Memon &lt;<a href="mailto:nabilmemon.ec@gmail.com" target="_blank">nabilmemon.ec@gmail.com</a>&gt; wrote:<br>
<br>
&gt; I see bro utilizing 100% CPU when in suspended state. And normal percentage CPU(roughly 15-20%) usage when in continued state.<br>
&gt;<br>
&gt; Why bro is taking up so much CPU when in suspended state?<br>
<br>
>From a historical explanation: I don&#39;t know, but maybe because it<br>
wasn&#39;t meant for general usage or only for some niche use-cases where<br>
some short-term high CPU usage was acceptable (the main use-case I<br>
know is currently in Zeek&#39;s test suite to cause determinism in some<br>
input/IPC tests that otherwise have subtle races).<br>
<br>
>From a technical explanation: likely it&#39;s because the suspend/continue<br>
functions don&#39;t remove the PktSrc file descriptor from the IO/polling<br>
loop so it&#39;s always considered &quot;ready&quot; but also never processes<br>
anything to drive it forward out of that &quot;ready&quot; state due to being<br>
&quot;suspended&quot;.<br>
<br>
The technicalities of suspend/continue performing an<br>
unregister/register the PktSrc FD are changeable if you want to make a<br>
GitHub issue for that enhancement (also may help if you provide more<br>
explanation of your use-case and the importance of this to it).<br>
Though might not expect any changes related to this happening until<br>
Zeek 3.2 or later -- 3.0.x has a different IO loop that&#39;s trickier to<br>
change, 3.1.x is a bit easier to change, but this isn&#39;t a clear-cut<br>
&quot;regression&quot; that suits a patch release, and 2.6.x or before are no<br>
longer supported.<br>
<br>
- Jon<br>
</blockquote></div>