Re: [this_cpu_xx V2 13/19] Use this_cpu operations in slub

[Christoph Lameter <cl@linux-foundation.org>]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1564 bytes --]

On Thu, 18 Jun 2009, Pekka Enberg wrote:

> Hi Christoph,
>
> On Wed, Jun 17, 2009 at 11:33 PM, <cl@linux-foundation.org> 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.