Bug 238675

Summary: POSIX timer (timer_create) limit is too low (32)
Product: Base System Reporter: Val Packett <val>
Component: standardsAssignee: freebsd-standards (Nobody) <standards>
Status: New ---    
Severity: Affects Only Me CC: cem, crest, emaste, kib
Priority: ---    
Version: CURRENT   
Hardware: Any   
OS: Any   
See Also: https://github.com/jiixyj/epoll-shim/issues/8

Description Val Packett 2019-06-18 00:17:30 UTC
epoll-shim https://github.com/jiixyj/epoll-shim implements the Linux timerfd API via threads and POSIX timers.

libwayland-server allocates a timerfd per client.

sys/timers.h defines TIMER_MAX as 32.

As a result.. you can only run 32 Wayland clients! :D And I've started hitting this limit in practice (especially with many WebKit processes).

Looks like on Linux, the limit of timers is RLIMIT_SIGPENDING which is 16382 by default: https://stackoverflow.com/questions/11903920/boost-deadline-timer-max-number-of-timers-in-linux

Our limit should be raised.
Comment 1 Conrad Meyer freebsd_committer freebsd_triage 2019-06-18 02:30:14 UTC
It might make more sense to fix epoll-shim to implement timerfd() API in a more scalable way.
Comment 2 crest 2019-06-18 11:14:32 UTC
Why are the timer limits so low? Even kqueue timers are limited to a "handful" of timers system wide. Is each non trivial process expected to reimplement the wheel?
Comment 3 Conrad Meyer freebsd_committer freebsd_triage 2019-06-18 16:56:17 UTC
Hm, if kqueue is limited to a handful of timers that seems like a problem.  Sorry, I'm unfamiliar with the subject area.
Comment 4 Konstantin Belousov freebsd_committer freebsd_triage 2019-06-22 18:48:05 UTC
(In reply to Conrad Meyer from comment #3)
Total number of kqueues per uid is limited by rlimit(2) RLIMIT_KQUEUES with no  default limit.  Global system number of kqueue timers is limited by sysctl kern.kq_calloutmax with the default value 4096.

TIMER_MAX defines the number of elements in the per-process structure, so bumping it arbitrary is not possible without reworking the code.  It probably can be increased to e.g. 64, but I doubt that this would be useful.