From owner-freebsd-hackers Thu Feb 6 19:16:12 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id TAA26769 for hackers-outgoing; Thu, 6 Feb 1997 19:16:12 -0800 (PST) Received: from who.cdrom.com (who.cdrom.com [204.216.27.3]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id TAA26748; Thu, 6 Feb 1997 19:16:07 -0800 (PST) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by who.cdrom.com (8.7.5/8.6.11) with ESMTP id SAA19884 ; Thu, 6 Feb 1997 18:39:06 -0800 (PST) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.2/8.7.3) id NAA09135; Fri, 7 Feb 1997 13:08:13 +1030 (CST) From: Michael Smith Message-Id: <199702070238.NAA09135@genesis.atrad.adelaide.edu.au> Subject: Re: Contigious (spelling?) allocation in kernel In-Reply-To: from Simon Shapiro at "Feb 6, 97 09:55:40 am" To: Shimon@i-Connect.Net (Simon Shapiro) Date: Fri, 7 Feb 1997 13:08:12 +1030 (CST) Cc: toor@dyson.iquest.net, freebsd-hackers@FreeBSD.ORG, freebsd-scsi@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 Simon Shapiro stands accused of saying: > > > 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. > > Thanx. > > If you (or someone else) please elaborate on the last sentence, > please... 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. > 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) > 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. > 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) > Thanx, Simon -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[