Date: Wed, 05 Feb 1997 21:33:57 -0800 From: "Justin T. Gibbs" <gibbs@narnia.plutotech.com> To: Simon Shapiro <Shimon@i-Connect.Net> Cc: freebsd-scsi@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: Contigious (spelling?) allocation in kernel Message-ID: <199702060533.VAA00624@narnia.plutotech.com> In-Reply-To: Your message of "Wed, 05 Feb 1997 19:33:54 PST." <XFMail.970205205354.Shimon@i-Connect.Net>
next in thread | previous in thread | raw e-mail | index | archive | help
>I need to allocate a contigious (one piece :-) block of memory for a DMA >scatter/gather list. If it is more than a page, you must use contigmalloc. contigmalloc may only be used close to boot time if you want to ensure it will work. >The HBA knows how to do scatter gather, but wants a >single pointer to a single block of memory that holds the entire list. >The SG structure is very plain, 32bits for length and 32bits for physical >address; 8 bytes. The thing is capable of up to 8192 entries, which give >us a possible list of 64KB per request list. You really think you're going to ever transfer a full 32MB of data in a single transaction? Even if you were, you'd have to do something special to the kernel since it currently only generates requests of at most 64k (its a silly restriction and it should die a horrible death). Assuming you did have a way to stuff 32MB through all of the layers, you'd probably be better off chopping that I/O into smaller chunks so as to reduce the amount of SG space you must allocate. At anything over 8k, the transaction overhead starts to become an increasingly small percentage of your I/O time, so dropping even down as low as 1MB per transaction may better utilize your resources. >As each HBA can have up to 256 concurrent requests, with who knows how >many more in the driver's queue, the list can grow quite impressively. >Since most requests are smaller, it seems very wasteful to allocate all >this memory upfront. So malloc is in order, but what are the options? You don't want to continuously malloc your SG list. This will kill your performance. If it is acceptable for the system to run with all 256 requests active at once, you have to be able to deal with all of the requests being allocated anyway, so you might as well pool them. >Thanx, > >Simon -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations ===========================================
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199702060533.VAA00624>