From owner-freebsd-hackers  Fri Apr  4 02:26:28 1997
Return-Path: <owner-hackers>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.5/8.8.5) id CAA00764
          for hackers-outgoing; Fri, 4 Apr 1997 02:26:28 -0800 (PST)
Received: from root.com (implode.root.com [198.145.90.17])
          by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id CAA00759
          for <freebsd-hackers@freebsd.org>; Fri, 4 Apr 1997 02:26:25 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by root.com (8.8.5/8.6.5) with SMTP id CAA10928; Fri, 4 Apr 1997 02:27:01 -0800 (PST)
Message-Id: <199704041027.CAA10928@root.com>
X-Authentication-Warning: implode.root.com: localhost [127.0.0.1] didn't use HELO protocol
To: borjam@we.lc.ehu.es (Borja Marcos)
cc: freebsd-hackers@freebsd.org
Subject: Re: new malloc 
In-reply-to: Your message of "Fri, 04 Apr 1997 12:02:51 +0200."
             <9704041002.AA17319@sirius.we.lc.ehu.es> 
From: David Greenman <dg@root.com>
Reply-To: dg@root.com
Date: Fri, 04 Apr 1997 02:27:01 -0800
Sender: owner-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

>	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.

   Both Poul-Henning's and the FreeBSD kernel's malloc allocate and insert
chunks at the head of the free queue - thus they already are LIFO.

-DG

David Greenman
Core-team/Principal Architect, The FreeBSD Project