Bug 238675 - POSIX timer (timer_create) limit is too low (32)
Summary: POSIX timer (timer_create) limit is too low (32)
Status: New
Alias: None
Product: Base System
Classification: Unclassified
Component: standards (show other bugs)
Version: CURRENT
Hardware: Any Any
: --- Affects Only Me
Assignee: freebsd-standards (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-06-18 00:17 UTC by Greg V
Modified: 2019-06-22 18:48 UTC (History)
4 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Greg V 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 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 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 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.