Date: Sat, 24 Dec 2022 05:42:07 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 268532] [patch] [libthr] pthread_mutex_destroy/pshared_gc slow when destroying many process shared locks Message-ID: <bug-268532-227@https.bugs.freebsd.org/bugzilla/>
next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D268532 Bug ID: 268532 Summary: [patch] [libthr] pthread_mutex_destroy/pshared_gc slow when destroying many process shared locks Product: Base System Version: CURRENT Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: bin Assignee: bugs@FreeBSD.org Reporter: atle.solbakken@gmail.com Created attachment 238992 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D238992&action= =3Dedit Patch The garbage collection function of process shared locks, pshared_gc, is cal= led whenever a process shared lock is destroyed. The GC function has a loop whi= ch checks entries in a hashmap of linked lists, looping through all registered locks. If a process has a lot of process shared locks, like more than a few hundre= d, the GC function causes destruction of these locks to take a long time (exponential). This is noticeable especially if many locks are to be destro= yed at the same time. There are probably multiple solutions for this, like calling the GC function only every X lock destruction, by having a time limit or by calling it upon some other event. The provided patch limits how often the GC function can run to at most ever= y 25 milliseconds per process. If i understand it correctly, the only potential = GC required after lock destruction should be in other processes, which have th= eir own timers. Best regards Atle --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-268532-227>