On Thu, 18 Jun 2009, Pekka Enberg wrote: > Hi Christoph, > > On Wed, Jun 17, 2009 at 11:33 PM, wrote: > > @@ -1604,9 +1595,6 @@ static void *__slab_alloc(struct kmem_ca > >        void **object; > >        struct page *new; > > > > -       /* We handle __GFP_ZERO in the caller */ > > -       gfpflags &= ~__GFP_ZERO; > > - > > This should probably not be here. Yes how did this get in there? Useless code somehow leaked in. > > A particular problem for the dynamic dma kmalloc slab creation is that the > > new percpu allocator cannot be called from an atomic context. The solution > > adopted here for the atomic context is to track spare elements in the per > > cpu kmem_cache array for non dma kmallocs. Use them if necessary for dma > > cache creation from an atomic context. Otherwise we just fail the allocation. > > OK, I am confused. Isn't the whole point in separating DMA caches that > we don't mix regular and DMA allocations in the same slab and using up > precious DMA memory on some archs? DMA caches exist to allocate memory in a range that can be reached by legacy devices. F.e. some SCSI controllers can only dma below 16MB. > So I don't think the above hunk is a good solution to this at all. We > certainly can remove the lazy DMA slab creation (why did we add it in > the first place?) but how hard is it to fix the per-cpu allocator to > work in atomic contexts? Lazy DMA creation was added to avoid having to duplicate the kmalloc array for a few rare uses of DMA caches.