From owner-freebsd-hackers Fri Apr 4 01:56:31 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id BAA29706 for hackers-outgoing; Fri, 4 Apr 1997 01:56:31 -0800 (PST) Received: from polaris.we.lc.ehu.es (polaris.we.lc.ehu.es [158.227.6.43]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id BAA29699 for ; Fri, 4 Apr 1997 01:56:25 -0800 (PST) Received: from sirius.we.lc.ehu.es by polaris.we.lc.ehu.es (SMI-8.6/SMI-SVR4) id LAA01442; Fri, 4 Apr 1997 11:54:49 +0200 From: borjam@we.lc.ehu.es (Borja Marcos) Received: by sirius.we.lc.ehu.es (4.1/SMI-4.1) id AA17319; Fri, 4 Apr 97 12:02:52 +0200 Message-Id: <9704041002.AA17319@sirius.we.lc.ehu.es> Subject: new malloc To: freebsd-hackers@freebsd.org Date: Fri, 4 Apr 1997 12:02:51 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hello, I have read with great interest Poul Henning-Kamp's article on the new malloc implementation for FreeBSD. It's funny to find a "twin" who has been solving a similar problem and has reached similar conclusions. In my case, I have been solving a more restricted problem, because what I have done is a buffer pool which offers buffers of a fixed size. Most of the techniques user in the new malloc are similar to mine, but I have had an idea that could be useful to the new malloc. My main concern when writing my "fixed-block_size_malloc" was accessing the least number of pages possible. In my case, it's used in a computer based voice logging system, with lots of processes and threads (the number of threads can reach 100) and a lot of IPC activity. The conclusion was: Why not organizing the memory blocks in a LIFO structure? If I do a malloc and malloc can give me the most recently used of all the possible blocks, the probability of causing a page-in is decreased. Depending on the system load, a great number of page-ins can be avoided. (I have observed this in my case) Of course, the same idea cn be applied adding a MRU policy to the allocation routine. Borja. -- *********************************************************************** Borja Marcos * Internet: borjam@we.lc.ehu.es Alangoeta, 11 1 izq * borjam@well.com 48990 - Algorta (Vizcaya) * borjamar@sarenet.es SPAIN * CompuServe: 100015,3502 *********************************************************************** NOTE TO BULK EMAIL SENDERS: When I receive an unsolicited advertisement, I take some time to send complaints not only to your service provider, but to the next level providers who serve your ISP.