thread taskq / unp_gc() using 100% cpu and stalling unix socket IPC
Alfred Perlstein
bright at mu.org
Wed Nov 14 16:06:38 UTC 2012
On Nov 14, 2012, at 2:42 AM, Markus Gebert <markus.gebert at hostpoint.ch> wrote:
>
> On 14.11.2012, at 04:30, Alfred Perlstein <bright at 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.
Yes. Looks good.
>
>
>> 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 looks to me as if it runs the gc when ANY type are in flight.
If you added refcounting then you could trust the refcounting so long as no unix sockets were in flight as its only the unix sockets that can cause cycles in a refcount based graph.
>
>> 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
>
More information about the freebsd-stable
mailing list