Date: Wed, 14 Nov 2012 11:42:48 +0100 From: Markus Gebert <markus.gebert@hostpoint.ch> To: Alfred Perlstein <bright@mu.org> Cc: freebsd-stable <freebsd-stable@freebsd.org> Subject: Re: thread taskq / unp_gc() using 100% cpu and stalling unix socket IPC Message-ID: <4DDA6862-6BE5-4EF4-B6B5-141DD9123C36@hostpoint.ch> In-Reply-To: <50A3104E.5000107@mu.org> References: <6908B498-6978-4995-B081-8D504ECB5C0A@hostpoint.ch> <007F7A73-75F6-48A6-9C01-E7C179CDA48A@hostpoint.ch> <50A3104E.5000107@mu.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 14.11.2012, at 04:30, Alfred Perlstein <bright@mu.org> wrote: > A couple of ideas: Thanks. > 1) convert the taskqueue to a callout, but only allow one to be queued = at a time. set the granularity. I think Konstantin's patch is going in this direction. > 2) I think you only need to actually run garbage collection on the = off-chance that you pass unix file descriptors, otherwise you can get = away with refcounting. Hm, isn't that whats done currently? gc is only scheduled if fds are = inflight while uipc_detach() is called. > It's hard for me to express the exact logic needed for this though. = I think you would need some way to simply do refcounting until there was = a unix socket descriptor in flight, then switch to gc. Either that or = make a sysctl that allows you administratively deny passing of unix = descriptors and just use refcounting. Markus
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4DDA6862-6BE5-4EF4-B6B5-141DD9123C36>