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

[Pekka Enberg <penberg@cs.helsinki.fi>]

On Thu, Jun 18, 2009 at 9:20 AM, Pekka Enberg<penberg@cs.helsinki.fi> 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.
>
>> @@ -2724,7 +2607,19 @@ static noinline struct kmem_cache *dma_k
>>        realsize = kmalloc_caches[index].objsize;
>>        text = kasprintf(flags & ~SLUB_DMA, "kmalloc_dma-%d",
>>                         (unsigned int)realsize);
>> -       s = kmalloc(kmem_size, flags & ~SLUB_DMA);
>> +
>> +       if (flags & __GFP_WAIT)
>> +               s = kmalloc(kmem_size, flags & ~SLUB_DMA);
>> +       else {
>> +               int i;
>> +
>> +               s = NULL;
>> +               for (i = 0; i < SLUB_PAGE_SHIFT; i++)
>> +                       if (kmalloc_caches[i].size) {
>> +                               s = kmalloc_caches + i;
>> +                               break;
>> +                       }
>> +       }
>
> [snip]
>
>> 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?
>
> 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?

Oh, and how does this work with the early boot slab code? We're
creating all the kmalloc caches with interrupts disabled and doing
per-cpu allocations, no?

                                                        Pekka

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>