Date: Thu, 8 Oct 2015 14:50:38 -0500 From: Eric van Gyzen <vangyzen@FreeBSD.org> To: freebsd-arch@freebsd.org, Jilles Tjoelker <jilles@stack.nl> Subject: Re: RFC: Automatically Reloading /etc/resolv.conf Message-ID: <5616C90E.6090509@FreeBSD.org> In-Reply-To: <20151007215558.GA41787@stack.nl> References: <5615886F.3060601@FreeBSD.org> <20151007215558.GA41787@stack.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
> Nitpick: the resolver has used poll instead of kqueue for a while, but > that does not fundamentally change your argument. I was looking at a 10.2-RELEASE system. Indeed, I see it using poll on head. Thanks. > Some glibc people think the extra stat may be too slow, though: > https://sourceware.org/bugzilla/show_bug.cgi?id=984 I added simple code to call stat() on every query and ran a benchmark. It reduces queries-per-second by 15.87%, so I definitely won't take that approach. >> When loading the file, open a kqueue and register for the appropriate >> events. Before each query, check for kevents. > > This sounds a bit scary in conjunction with code that bluntly closes > file descriptors it does not know about. That's true, but such code would break a variety of other facilities, such as syslog. I'll keep this in mind. > Also, kqueues do not inherit across fork, so the resolver needs some > sort of atfork handler. I hadn't thought of that. Thanks. >> NetBSD uses this approach. It mitigates most of the space-cost by using >> a shared pool of res_state objects, instead of one per thread [that uses >> the resolver]. On each query, a thread allocates/borrows a res_state >> from the pool, uses it, and returns it. So, the number of objects is >> only the high water mark of the number of threads _concurrently_ issuing >> resolver queries. > > Is there code that depends on implicit per-thread res_state objects? If > so, this will break it. I'm just describing NetBSD's current approach. I don't plan to adopt this in FreeBSD. To answer your question, though, I don't know if such code exists. > The NextBSD people have a more efficient alternative notify(3). Using > that, resolvconf(8) can cause a counter in shared memory to be > incremented, which can be detected efficiently by the resolver in each > process. The stat() approach need not wait for this, though. I didn't know about this. It sounds rather useful. Thanks! Eric
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5616C90E.6090509>