Date: Thu, 15 Aug 2002 22:27:26 -0700 From: Alfred Perlstein <bright@mu.org> To: David Greenman-Lawrence <dg@dglawrence.com> Cc: David Greenman <dg@FreeBSD.org>, cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/kern uipc_socket2.c Message-ID: <20020816052726.GN75574@elvis.mu.org> In-Reply-To: <20020815221609.E42978@nexus.root.com> References: <200208160508.g7G58kRZ098250@freefall.freebsd.org> <20020815221609.E42978@nexus.root.com>
next in thread | previous in thread | raw e-mail | index | archive | help
* David Greenman-Lawrence <dg@dglawrence.com> [020815 22:25] wrote: > >dg 2002/08/15 22:08:46 PDT > > > > Modified files: > > sys/kern uipc_socket2.c > > Log: > > Rewrote the space check algorithm in sbreserve() so that the extremely > > expensive (!) 64bit multiply, divide, and comparison aren't necessary > ... > > The 64bit math in this function was measured in some kernel profiles as > > being as much as 5-8% of the total overhead of the TCP/IP stack and > > I'm looking at calcru() as well, since is does four 64bit divides and > was as expensive as sbreserve() in my profiles. The __qdivrem function > that does the 64bit divide appears to consume several thousand instructions > in the common case. Something to avoid if at all possible. Any idea on how to setup warnings when some threshold of 64 bit math is reached? I know this entirely arbitrary, but it would be interesting and obviously benificial if we could easily find and fix more instances of this in a somewhat automated fashion. -- -Alfred Perlstein [alfred@freebsd.org] [#bsdcode/efnet/irc.prison.net] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020816052726.GN75574>