From owner-freebsd-hackers  Fri Feb  7 12:41:30 1997
Return-Path: <owner-hackers>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.5/8.8.5) id MAA18331
          for hackers-outgoing; Fri, 7 Feb 1997 12:41:30 -0800 (PST)
Received: from sendero.i-connect.net ([206.190.144.100])
          by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id MAA18325;
          Fri, 7 Feb 1997 12:41:26 -0800 (PST)
Received: (from shimon@localhost)
          by sendero.i-connect.net (8.8.5/8.8.4)
	  id NAA20750; Fri, 7 Feb 1997 13:40:32 -0800 (PST)
Message-ID: <XFMail.970207134032.Shimon@i-Connect.Net>
X-Mailer: XFMail 1.1-alpha [p0] on FreeBSD
Content-Type: text/plain; charset=iso-8859-8
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
In-Reply-To: <199702070238.NAA09135@genesis.atrad.adelaide.edu.au>
Date: Fri, 07 Feb 1997 12:24:52 -0800 (PST)
Organization: iConnect Corp.
From: Simon Shapiro <Shimon@i-Connect.Net>
To: Michael Smith <msmith@atrad.adelaide.edu.au>
Subject: Re: Contigious (spelling?) allocation in kernel
Cc: freebsd-scsi@freebsd.org, freebsd-hackers@freebsd.org,
        toor@dyson.iquest.net
Sender: owner-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk


Hi Michael Smith;  On 07-Feb-97 you wrote: 

...

> Er, from my understanding the kva space tends to become fragmented, and
> your chances of being able to allocate contiguous memory tend to
> be reduced.

So failure is defined here as ``refusal to provide resource requested'',
but not ``crash the system or other unexpected result''.
This we can live with.

> > I can re-structure the driver a bit (make it more risky), to 
> > avoid the need for large contigious blocks, but the (obvious)
> > question is:  Does the kernel malloc guarantee that allocations
> > smaller than (or equal to) a page are in the same page?
> 
> Can't answer that, sorry.  Look at the source 8)

I think the answer is yes.

> > Having a page or less, limits the Scatter/Gather operations in
> > the kernel, for most hardware, to 512 entries (segments).  
> > Under high fragmentation, this can result in 256KB-2MB floating
> > limit.  While not a problem for most applications (mine
> > included), it is still a limit that is not absolutely necessary.
> 
> TBH, a 256K I/O is likely to be bigger than most peripherals can do
> anything useful with.  I would be inclined to say that the 
> overhead of splitting that into seperate transactions is likely
> to be small compared with the size of the transaction.

It all depends on the device.  Some high speed tapes, printers,
CD Writers, can use large blocks.  Most O/S's do not know what to do
with large blocks, though...

> > 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.
> 
> They're right on the ball; avoid allocating memory on the fly wherever
> possible. 8)

I know, I know... :-)

thanx,

Simon