[Zeek] Input framework

Jon Siwek jsiwek at corelight.com
Fri May 29 09:42:30 PDT 2020


On Thu, May 28, 2020 at 9:55 PM Nabil Memon <nabilmemon.ec at gmail.com> wrote:

> I see bro utilizing 100% CPU when in suspended state. And normal percentage CPU(roughly 15-20%) usage when in continued state.
>
> Why bro is taking up so much CPU when in suspended state?

>From a historical explanation: I don't know, but maybe because it
wasn't meant for general usage or only for some niche use-cases where
some short-term high CPU usage was acceptable (the main use-case I
know is currently in Zeek's test suite to cause determinism in some
input/IPC tests that otherwise have subtle races).

>From a technical explanation: likely it's because the suspend/continue
functions don't remove the PktSrc file descriptor from the IO/polling
loop so it's always considered "ready" but also never processes
anything to drive it forward out of that "ready" state due to being
"suspended".

The technicalities of suspend/continue performing an
unregister/register the PktSrc FD are changeable 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).
Though might not expect any changes related to this happening until
Zeek 3.2 or later -- 3.0.x has a different IO loop that's trickier to
change, 3.1.x is a bit easier to change, but this isn't a clear-cut
"regression" that suits a patch release, and 2.6.x or before are no
longer supported.

- Jon


More information about the Zeek mailing list