Date: Wed, 01 Jun 2011 17:05:28 -0700 From: Doug Barton <dougb@FreeBSD.org> To: Hiroki Sato <hrs@FreeBSD.org> Cc: bz@FreeBSD.org, freebsd-rc@FreeBSD.org Subject: Re: afexists() Message-ID: <4DE6D3C8.1050503@FreeBSD.org> In-Reply-To: <20110601.130434.820821962809263631.hrs@allbsd.org> References: <4DE55A48.8090508@FreeBSD.org> <F1D28BBA-2956-46FF-A71E-B08CE20BFEDF@FreeBSD.org> <4DE588B4.7090908@FreeBSD.org> <20110601.130434.820821962809263631.hrs@allbsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 05/31/2011 21:04, Hiroki Sato wrote: > Doug Barton<dougb@FreeBSD.org> wrote > in<4DE588B4.7090908@FreeBSD.org>: > > do> >> Attached is a patch which caches a positive result for support for a > do> >> given address family. I don't think caching negative results is a good > do> >> idea since that could change as the boot progresses. > do> > > do> > Not yet for inet or inet6 (or ipx I think) but atm might be loadable. > do> > Looking ahead that's certainly true though maybe also considering > do> > virtualization maybe. > do> > do> I think it's generally safer not to cache the negative answer, and > do> from what you're saying it sounds like it may add some future-proofing > do> as well. And yes, I did also have VMs in mind, since I'm doing a lot > do> of work in that area atm. > > Caching the results looks good to me, but I think it is rather safer > to keep the results unchanged while a script is running regardless of > the value. This is because the rc.d scripts do not assume afexists() > returns different values in a run (at least at this moment) , and > writing a script to support such a dynamically-changed condition > would be quite difficult. I understand what you're saying, but I'm not sure which is the worse problem. However, since the likelihood of the situation happening are very small, I think leaving it as is for now is the safest alternative. We can deal with any problems if/when they arise. > do> >> I plan to commit this on Friday if there are no objections. > do> > > do> > I am not sure it helps but I see no regression, so if you want, feel > do> > free to go ahead. > do> > do> If you can assume that each call to the sysctl takes 100 ms (which is > do> a WAG for sake of argument), then saving 25 of them will result in us > do> booting 2.5 seconds faster. I'd ultimately like to cut the > do> rc.d-related portion of the boot in half, if not more, so every little > do> bit helps. > > I think it would be great if it is possible to create a wrapper > function for testing and caching. I expects testing kern.features.* > is likely added again to somewhere in rc.d scripts, and adding a long > lines of "[ -n ... ]&& return 0; if sysctl...; fi" each time > degrades readability. I think that's definitely an interesting idea, and I'd love to review patches that implement it. :) Unfortunately I don't have time to do so atm, and would prefer to focus on a specific case where a small optimization leads to a big gain. Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4DE6D3C8.1050503>