Messages in this thread | | | Date | Mon, 11 Jun 2007 14:14:49 -0700 | From | Andrew Morton <> | Subject | Re: [Intel-IOMMU 02/10] Library routine for pre-allocat pool handling |
| |
On Mon, 11 Jun 2007 13:44:42 -0700 "Keshavamurthy, Anil S" <anil.s.keshavamurthy@intel.com> wrote:
> In the first implementation of ours, we had used mempools api's to > allocate memory and we were told that mempools with GFP_ATOMIC is > useless and hence in the second implementation we came up with > resource pools ( which is preallocate pools) and again as I understand > the argument is why create another when we have slab allocation which > is similar to this resource pools.
Odd. mempool with GFP_ATOMIC is basically equivalent to your resource-pools, isn't it?: we'll try the slab allocator and if that failed, fall back to the reserves.
It's missing the recharge-from-a-kernel-thread functionality but that can be added easily enough if it's useful. It's slightly abusive of the mempool philosophy, but it's probably better to do that than to create a new and very-similar thing.
> Hence, can I assume that the conclusion of this > discussion is to use kmem_cache_alloc() functions > to allocate memory in dma_map_{single|sg} API's? > > Again, if dma_map_{single|sg} API's fails due to > failure to allocate memory, the only thing that can > be done is to panic as this is what few of the other > IOMMU implementation is doing today.
If the only option is to panic then something's busted. If it's network IO then there should be a way of dropping the frame. If it's disk IO then we should report the failure and cause an IO error.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |