From owner-freebsd-hackers  Thu Feb  6 17:07:07 1997
Return-Path: <owner-hackers>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.5/8.8.5) id RAA19639
          for hackers-outgoing; Thu, 6 Feb 1997 17:07:07 -0800 (PST)
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19])
          by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA19616;
          Thu, 6 Feb 1997 17:07:00 -0800 (PST)
Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.3/8.6.9) id JAA06777; Fri, 7 Feb 1997 09:45:47 +1100
Date: Fri, 7 Feb 1997 09:45:47 +1100
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199702062245.JAA06777@godzilla.zeta.org.au>
To: Shimon@i-Connect.Net, toor@dyson.iquest.net
Subject: Re: Contigious (spelling?) allocation in kernel
Cc: freebsd-hackers@freebsd.org, freebsd-scsi@freebsd.org
Sender: owner-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

>> Take a look at contigmalloc() or vm_page_alloc_contig()
>> as defined in /sys/vm/vm_page.c.  These are almost
>> guaranteed NOT to work after the system is fully up.
>...
>If you (or someone else) please elaborate on the last sentence,
>please...

Physical memory gets fragmented after the system has been running
for a little while, so the chance of finding N physically contiguous
is small if N > 1.

>question is:  Does the kernel malloc guarantee that allocations
>smaller than (or equal to) a page are in the same page?

Yes.

>BACKGROUND:  One of my engineers, who is heavily involved in 
>Linux SCSI development is strongly opposed to calling malloc on
>demand in a device driver.  He quotes heavy performance
>penalties, and worse;  Failure (under heavy load) to obtain the
>memory when needed.

Good advice.  The performance penalties for nonblocking mallocs
aren't large under FreeBSD, except when you allocate pages that
would be better used for something else, but failure (under not
so heavy load) is likely if you attempt to allocate more than a
page or two.

Bruce