Re: [PATCH] ohci1394: dma_pool_destroy while in_atomic() && irqs_disabled()

[David Brownell <david-b@pacbell.net>]

> > Jody - Is the 200K waste for sure or do you want me to verify it by some 
> > means? ( Reason I am asking is firstly, Dave Brownell was quite sure it 
> > wasn't that costly and secondly, I am hoping it isn't.. ;)
> 
> I'm not sure, but I looked through the code and it seems to allocate:
>  - 16 buffers of 2x PAGE_SIZE (= 131072 on i386)
>  - 16 buffers of PAGE_SIZE (= 65536 on i386)
>  - various other smaller structures.
> 
> I'm not sure how to actually _measure_ how much memory this is using.
> slabinfo isn't useful, at least on my system, because the 1394
> allocations get lost in the noise of other activity.

Those allocations could be from _using_ a dma pool ... but they're
not from just creating one!

The cost of creating the dma_pool is the cost of one small kmalloc()
plus (the expensive part) the /sys/devices/.../pools sysfs attribute
is created along with the first pool.  (Use that instead of slabinfo
for those pool allocations.)  That's why the normal spot to create and
destroy dma pools is in driver probe() and remove() methods.

If you want to allocate gobs of other stuff at the same time, that's
your choice ... but it'd be a separate issue.  Cost to create a
dma_pool is significantly less than PAGE_SIZE, and there's no good
reason to allocate or destroy those pools anywhere near an IRQ context.

- Dave