Date: Thu, 06 Feb 1997 09:55:40 -0800 (PST) From: Simon Shapiro <Shimon@i-Connect.Net> To: "John S. Dyson" <toor@dyson.iquest.net> Cc: freebsd-hackers@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG Subject: Re: Contigious (spelling?) allocation in kernel Message-ID: <XFMail.970206131700.Shimon@i-Connect.Net> In-Reply-To: <199702060512.AAA10010@dyson.iquest.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi John S. Dyson; On 06-Feb-97 you wrote: > 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... 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? 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. Any opposing opinions (before I re-code the darn thing :-)? 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. Thanx, Simon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.970206131700.Shimon>