On-stack allocation of DMA S/G lists

[Peter Jeremy]

On 2012-Aug-07 10:09:42 -0600, Ian Lepore <freebsd at damnhippie.dyndns.org> wrote:
>And just for the record, looking at the problem from an even more
>distant vantage... is there really a problem with stack-allocating the
>segments?  On a 64-bit arch the struct is like 16 bytes.  Typical usage
>is to allocate a tag allowing 1 or just a few segments.  Is anyone
>really going to create a tag specifying hundreds of segments that would
>overflow the stack?

The example that led me to study the code was drm(4).  Video cards
typically require fairly large allocations (32MB in my case) but don't
require the RAM to be contiguous - ie it created a tag with 8192
segments in my case.  This may not be relevant to most arm or mips
hosts but drm(4) is MI code that can (theoretically) be built on these
architectures and is a real example where a tag can have many
segments.

>  If they try, wouldn't failing the tag create be good enough?

No.  The caller specifies the hardware limits for the device.  They
should not need to take into account implementation details that
mean the full hardware capabilities are not needed.  We don't fail
a tag create if it specifies that RAM above 4GB can be used when
we don't have any.  Why should be fail a tag create that allows the
use of up to 8192 tags when we only support 1?

-- 
Peter Jeremy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-arm/attachments/20120807/4e2b6f8c/attachment.pgp