Date: Fri, 07 Feb 1997 12:24:52 -0800 (PST) From: Simon Shapiro <Shimon@i-Connect.Net> To: Michael Smith <msmith@atrad.adelaide.edu.au> Cc: freebsd-scsi@freebsd.org, freebsd-hackers@freebsd.org, toor@dyson.iquest.net Subject: Re: Contigious (spelling?) allocation in kernel Message-ID: <XFMail.970207134032.Shimon@i-Connect.Net> In-Reply-To: <199702070238.NAA09135@genesis.atrad.adelaide.edu.au>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.970207134032.Shimon>