From owner-freebsd-rc@FreeBSD.ORG Wed Jun 1 00:32:55 2011 Return-Path: <owner-freebsd-rc@FreeBSD.ORG> Delivered-To: freebsd-rc@FreeBSD.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 4ED7F106566C; Wed, 1 Jun 2011 00:32:55 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 65-241-43-5.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 1F24014DC71; Wed, 1 Jun 2011 00:32:53 +0000 (UTC) Message-ID: <4DE588B4.7090908@FreeBSD.org> Date: Tue, 31 May 2011 17:32:52 -0700 From: Doug Barton <dougb@FreeBSD.org> Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.17) Gecko/20110429 Thunderbird/3.1.10 MIME-Version: 1.0 To: "Bjoern A. Zeeb" <bz@FreeBSD.org> References: <4DE55A48.8090508@FreeBSD.org> <F1D28BBA-2956-46FF-A71E-B08CE20BFEDF@FreeBSD.org> In-Reply-To: <F1D28BBA-2956-46FF-A71E-B08CE20BFEDF@FreeBSD.org> X-Enigmail-Version: 1.1.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-rc@FreeBSD.org Subject: Re: afexists() X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion related to /etc/rc.d design and implementation." <freebsd-rc.freebsd.org> List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-rc>, <mailto:freebsd-rc-request@freebsd.org?subject=unsubscribe> List-Archive: <http://lists.freebsd.org/pipermail/freebsd-rc> List-Post: <mailto:freebsd-rc@freebsd.org> List-Help: <mailto:freebsd-rc-request@freebsd.org?subject=help> List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-rc>, <mailto:freebsd-rc-request@freebsd.org?subject=subscribe> X-List-Received-Date: Wed, 01 Jun 2011 00:32:55 -0000 On 05/31/2011 17:19, Bjoern A. Zeeb wrote: > On May 31, 2011, at 9:14 PM, Doug Barton wrote: > > Hey, > >> I don't have any specific objections to this change, although adding more calls to afexists() highlights an issue I addressed previously in looking at network.subr. On my system (with IPv6) it's called over 25 times at each boot, which given that it's a moderately expensive test indicates an opportunity for optimization. > > Yeah, it's still a lot cheaper than going into the various configurations running ifconfigs etc. Especially it does not yield errors this way;) Oh, I agree completely. I'm not saying, "we shouldn't do this," only that we should do it smarter. >> Attached is a patch which caches a positive result for support for a given address family. I don't think caching negative results is a good idea since that could change as the boot progresses. > > Not yet for inet or inet6 (or ipx I think) but atm might be loadable. Looking ahead that's certainly true though maybe also considering virtualization maybe. I think it's generally safer not to cache the negative answer, and from what you're saying it sounds like it may add some future-proofing as well. And yes, I did also have VMs in mind, since I'm doing a lot of work in that area atm. >> I plan to commit this on Friday if there are no objections. > > I am not sure it helps but I see no regression, so if you want, feel free to go ahead. If you can assume that each call to the sysctl takes 100 ms (which is a WAG for sake of argument), then saving 25 of them will result in us booting 2.5 seconds faster. I'd ultimately like to cut the rc.d-related portion of the boot in half, if not more, so every little bit helps. Thanks for the review, 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/