From owner-freebsd-hackers  Fri Apr  4 14:48:04 1997
Return-Path: <owner-hackers>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.5/8.8.5) id OAA08683
          for hackers-outgoing; Fri, 4 Apr 1997 14:48:04 -0800 (PST)
Received: from pdx1.world.net (pdx1.world.net [192.243.32.18])
          by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA08678
          for <freebsd-hackers@freebsd.org>; Fri, 4 Apr 1997 14:48:01 -0800 (PST)
From: proff@suburbia.net
Received: from suburbia.net (suburbia.net [203.4.184.1]) by pdx1.world.net (8.7.5/8.7.3) with SMTP id OAA01707 for <freebsd-hackers@freebsd.org>; Fri, 4 Apr 1997 14:50:13 -0800 (PST)
Received: (qmail 6879 invoked by uid 110); 4 Apr 1997 12:49:13 -0000
Message-ID: <19970404124913.6878.qmail@suburbia.net>
Subject: Re: new malloc
In-Reply-To: <199704041027.CAA10928@root.com> from David Greenman at "Apr 4, 97 02:27:01 am"
To: dg@root.com
Date: Fri, 4 Apr 1997 22:49:13 +1000 (EST)
Cc: borjam@we.lc.ehu.es, freebsd-hackers@freebsd.org
X-Mailer: ELM [version 2.4ME+ PL28 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
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

You also get the benefit of a greater chance of the page being in 
cache.

Cheers,
Julian.