From owner-freebsd-hackers Thu Jul 6 8:58: 7 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from falla.videotron.net (falla.videotron.net [205.151.222.106]) by hub.freebsd.org (Postfix) with ESMTP id 3CD2137B536 for ; Thu, 6 Jul 2000 08:58:04 -0700 (PDT) (envelope-from bmilekic@dsuper.net) Received: from modemcable009.62-201-24.mtl.mc.videotron.net ([24.201.62.9]) by falla.videotron.net (Sun Internet Mail Server sims.3.5.1999.12.14.10.29.p8) with ESMTP id <0FXA00EVI9CR6G@falla.videotron.net> for freebsd-hackers@FreeBSD.ORG; Thu, 6 Jul 2000 11:50:52 -0400 (EDT) Date: Thu, 06 Jul 2000 11:52:59 -0400 (EDT) From: Bosko Milekic Subject: Re: mbuf re-write(s), v 0.1 In-reply-to: X-Sender: bmilekic@jehovah.technokratis.com To: Poul-Henning Kamp Cc: freebsd-hackers@FreeBSD.ORG Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 6 Jul 2000, Bosko Milekic wrote: > I've recently had the chance to get some profiling done. > > I used metrics obtained from gprof, as well as the (basic block > length) * (number of executions) metric generated by kernbb. The latter > reveals an approximate 30% increase in the new code, but does not > necessarily imply that time of execution is increased by that amount. > gprof makes a fair estimate on execution time, and reveals that the > new code is, worse case scenario 30% slower, and best case scenario, > negligeably slower. Of course, I'm leaving out some details here, because > I've decided to change things a little, in order to further improve (and > significantly, at that) the performance of the new code. Note however > that the 30% overall APPROXIMATE increase is not something I would > consider significant, especially since the allocator/free routines don't > hold much %time, and are not the bottleneck in any of the call graphs. I > did decide to make drastic changes, however, in order to maintain with > the 0-tolerance policy, even if it involves somewhat getting rid of a > cleaner interface and adopting a "kernel process." See below. You can disregard the above data. I actually found something detrimental (seriously) to performance. During MFREE, the code would free the page in question if at the time the number of mbufs on the free list exceeds (even by a little) min_on_avail. This is fine. The problem was in MGET/MGETHDR where the code would explicitly allocate when how==M_WAIT and number of mbufs on free list < min_on_avail (this was a feeble attempt at making M_NOWAIT allocations even faster). The potential problem is not so obvious: numerous M_WAIT allocs will ALWAYS allocate a page from the map while min_on_avail < mbufs on free lists. And, MFREE would almost ALWAYS have to free back to the map as at this point, the number of mbufs on the free lists fairly quickly reaches min_on_avail. So what would happen is a page would be allocated, freed, allocated, freed, etc. m_get + m_free would be an endless cycle of m_mbmapalloc and m_mbmapfree, which increases overhead significantly. After fixing MGET/MGETHDR, I'm getting more promising results. I'll get some hard data and post it later tonight, hopefully. Oh, and I'm still open to the kernel process idea. I'll need one such beast anyway, because it will help minimize page fragmentation for the allocator, on request. -- Bosko Milekic * Voice/Mobile: 514.865.7738 * Pager: 514.921.0237 bmilekic@technokratis.com * http://www.technokratis.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message