On 04/07/2015 03:56 PM, Thiago Macieira wrote: > On Tuesday 07 April 2015 15:23:24 Keane, Erich wrote: >> Our biggest CPU intensity currently is watching the ethernet/wifi >> adapters for change and JSON parsing/generation. Otherwise we are >> pretty low-hit. > > In an ideal world, "watching" should not be CPU intensive. It should require > exactly 0 cycles in user-space to watch: you call select(2) or poll(2) or > equivalent, then sleep until something of interest happens. Anything that > requires spending CPU time is a flawed design. > > In real world, we have to put up with flawed APIs from libraries we use. I > don't know if Linux netlink supports watching for configuration changes. > >> I agree that a solid audit to remove a bunch of the threading would be a >> great feature as well, but I suspect that SOME threading would be >> necessary, but it could definitely make the glib2 less necessary. >
There are a few things that can be done to address this, with some of them being Linux specific. But if we have things extracted for Linux then using those is good, and can quickly drop the current CPU load. Similar to using pipe2(), we can use the better calls when present. I'd offered to help the implementor of the current solution, but never heard back.
