High cpu-usage on linux about c-open HOT 4 CLOSED

I noticed high CPU load as well (23%), but found it to be the CO_JOB_PERIODIC timer which fires every ms with the SIGEV_THREAD notification, i.e. spawning a new thread every ms. I get high CPU usage without ever receiving a CAN message so I doubt the repeated select() is the (only) culprit.

from c-open.

Verified that idle CPU consumption scales with the timer period, i.e. 2 ms gives me half the load.

It would be nice if the clients of the periodic job feature could say when they are expiring, so that the timer can be armed to the time required instead of periodically. Since all callees in co_handle_periodic() seems to end up using co_is_expired() to check now against a timestamp and fixed period, this should be easily implemented by returning the time left from co_is_expired() and propagating the minimum value up the call chain to co_main() which can re-arm the timer.

Then also the CO_JOB_PERIODIC message must be force sent whenever any event causes a timer to be set, to recalculate the timeout. Maybe co_handle_periodic() can be called every iteration of the co_main() loop to cover all cases where the event passes trough the main thread? Are there others?

The main loop could probably even use the timeout feature of os_mbox_fetch() to wake up at the right time instead of keeping a separate timer around.

from c-open.

The select() issue should be fixed now, by using epoll(). The timers were reworked to use SIGEV_THREAD_ID, this avoids creating a new thread whenever the timer fires and improves the cpu-usage somewhat. It still seems fairly expensive to do periodic work at 1000Hz though.

I like the idea of calculating the next timeout dynamically, assuming jitter can be avoided (for other platforms where the timers are more reliable). Could you create a new issue for that?

from c-open.

Closed, but see #6

from c-open.