Date: Wed, 6 Nov 2002 16:40:10 -0500 (EST) From: Jeff Roberson <jroberson@chesapeake.net> To: Nate Lawson <nate@root.org> Cc: Terry Lambert <tlambert2@mindspring.com>, <arch@FreeBSD.ORG> Subject: Re: malloc(9) performance Message-ID: <20021106163703.X1374-100000@mail.chesapeake.net> In-Reply-To: <Pine.BSF.4.21.0211061317110.15820-100000@root.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 6 Nov 2002, Nate Lawson wrote: > On Wed, 6 Nov 2002, Terry Lambert wrote: > > Nate Lawson wrote: > > > (*) For me, fast enough means sustaining 100000 small (400 byte) and big > > > (64k) allocations/frees per second (one every 10 us). Maximum memory in > > > use at any point in time would be a few MB. Latency is my main concern > > > and memory fragmentation much less so. > > > > For me, the number is closer to 600,000: theoretically, this should > > be the combined mbuf and tcpcb connection struct allocation rate, > > given the maximum possible connection per second rate on a Gigabit > > ethernet's packets-per-secon throughput. > > I'm going to get really flamed for this but I did a short test of the > userland malloc and found that I get 33000 mallocs/sec when grabbing 64k > (and then touching one byte on each page) compared to 1800/s when I add in > the small mallocs (one 608 byte, one 400 byte). So I may be sticking with > a private freelist for the small allocations and use malloc for the large > buf. Of course, profiling and real tests would be much better but I just > need to make a quick decision for now. > > -Nate > I do not currently have performance numbers for malloc(9). They will not have anything at all to do with the performance of the library malloc. It has to do semi expensive system calls to do its job. I only did system level benchmarks against the old malloc and it did very well. The fast path for malloc is only the overhead of a lock, poping an item off of a stack, and an unlock. It should be quite fast. It would be trivial to write a module that would time malloc and print out some results. Could you try this? If not I can put it on my to do list. Cheers, Jeff To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20021106163703.X1374-100000>