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

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

On Saturday 19 February 2005 12:50 pm, Parag Warudkar wrote:
> On Saturday 19 February 2005 02:36 pm, David Brownell wrote:
> > 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.
> 
> What's the format of /sys/devices/.../pools (Name of pool, ? ? ? ?) ?  Can the 
> memory consumption be derived from it? 

See what drivers/base/dmapool.c tells you; yes that
consumption can be derived from the pool statistics.


> Here is what the ohci pools look during data read (Kino->Capture) and after 
> closing Kino -
> 
> During Kino Capture
> [root@localhost pci0000:00]# cat ./0000:00:0a.0/0000:02:00.0/pools
> poolinfo - 0.1
> ohci1394 rcv prg   16  256   16  1 ------------------> This one is in question
> ohci1394 trm prg   32   64   64  1
> ohci1394 trm prg   32   64   64  1
> ohci1394 rcv prg    4  256   16  1
> ohci1394 rcv prg    4  256   16  1

I suggest you get rid of the spaces in those names, to make it
easier to use things like "awk" to massage those numbers.  The
"ohci1394" is implied by the fact that no other driver could
be bound to that device, for example.

In this case, other than the fact that you've created multiple
pools with the same names (!), that line translates to 16 blocks
in use out of 256 available, 16 bytes per block, just one page.

I suspect that on some systems it should be bumping up the minimum
block size to match the CPU cacheline size.

- Dave