Date: Fri, 4 Apr 1997 12:02:51 +0200 (MET DST) From: borjam@we.lc.ehu.es (Borja Marcos) To: freebsd-hackers@freebsd.org Subject: new malloc Message-ID: <9704041002.AA17319@sirius.we.lc.ehu.es>
next in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9704041002.AA17319>