Date: Thu, 06 Jul 2000 11:52:59 -0400 (EDT) From: Bosko Milekic <bmilekic@dsuper.net> To: Poul-Henning Kamp <phk@critter.freebsd.dk> Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: mbuf re-write(s), v 0.1 Message-ID: <Pine.BSF.4.21.0007061143100.3744-100000@jehovah.technokratis.com> In-Reply-To: <Pine.BSF.4.21.0007060903010.2989-100000@jehovah.technokratis.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0007061143100.3744-100000>