Bug 238675

Summary:	POSIX timer (timer_create) limit is too low (32)
Product:	Base System	Reporter:	Val Packett <val>
Component:	standards	Assignee:	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

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.

Comment 5 Jan Beich freebsd_committer

2024-06-13 20:39:04 UTC

Obsolete after base af93fea71038?

Comment 6 Ed Maste freebsd_committer

2024-06-14 15:10:56 UTC

(In reply to Jan Beich from comment #5)
I think so -- the issue in the Subject is still true (TIMER_MAX is still 32), but the user-facing issue has been addressed with the introduction of timerfd to the native syscall interface.