Date: Fri, 7 Feb 1997 13:08:12 +1030 (CST) From: Michael Smith <msmith@atrad.adelaide.edu.au> To: Shimon@i-Connect.Net (Simon Shapiro) Cc: toor@dyson.iquest.net, freebsd-hackers@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG Subject: Re: Contigious (spelling?) allocation in kernel Message-ID: <199702070238.NAA09135@genesis.atrad.adelaide.edu.au> In-Reply-To: <XFMail.970206131700.Shimon@i-Connect.Net> from Simon Shapiro at "Feb 6, 97 09:55:40 am"
next in thread | previous in thread | raw e-mail | index | archive | help
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 [[
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199702070238.NAA09135>