Handling of GFP_WAIT in the slub and slab allocators

Handling of GFP_WAIT in the slub and slab allocators

[Nicolas Palix]

Hi,

In the SLUB allocator, the GFP_WAIT mask bit is used
in allocate_slab to decide if local_irq_enable must be called.
This test is done again later to decide if local_irq_disable
must be called.

I notice that in the SLAB allocator, local_irq_save and
local_irq_restore are called in slab_alloc_node and slab_alloc without
checking the GFP_WAIT bit of the flags parameter.

Am I missing something or is there something to be fixed in the SLAB allocator ?

As I understand the code so far, this could change the state of the irqs
during the execution of start_kernel (init/main.c) for instance.

Could someone give me enlightenment about those points ?

Regards,
--
Nicolas Palix

--
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>

Re: Handling of GFP_WAIT in the slub and slab allocators

[Christoph Lameter]

On Mon, 10 Jun 2013, Nicolas Palix wrote:

> I notice that in the SLAB allocator, local_irq_save and
> local_irq_restore are called in slab_alloc_node and slab_alloc without
> checking the GFP_WAIT bit of the flags parameter.

SLAB does the same as SLUB. Have a look at mm/slab.c:cache_grow()

--
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>

Re: Handling of GFP_WAIT in the slub and slab allocators

[Nicolas Palix]

On Mon, Jun 10, 2013 at 5:18 PM, Christoph Lameter <cl@gentwo.org> wrote:
> On Mon, 10 Jun 2013, Nicolas Palix wrote:
>
>> I notice that in the SLAB allocator, local_irq_save and
>> local_irq_restore are called in slab_alloc_node and slab_alloc without
>> checking the GFP_WAIT bit of the flags parameter.
>
> SLAB does the same as SLUB. Have a look at mm/slab.c:cache_grow()

I agree and it is the same for mm/slab.c:fallback_alloc() but
why is it not also required for mm/slab.c:slab_alloc_node()
and mm/slab.c:slab_alloc() which both manipulate the local irqs?



--
Nicolas Palix

--
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>

Re: Handling of GFP_WAIT in the slub and slab allocators

[Christoph Lameter]

On Mon, 10 Jun 2013, Nicolas Palix wrote:

> On Mon, Jun 10, 2013 at 5:18 PM, Christoph Lameter <cl@gentwo.org> wrote:
> > On Mon, 10 Jun 2013, Nicolas Palix wrote:
> >
> >> I notice that in the SLAB allocator, local_irq_save and
> >> local_irq_restore are called in slab_alloc_node and slab_alloc without
> >> checking the GFP_WAIT bit of the flags parameter.
> >
> > SLAB does the same as SLUB. Have a look at mm/slab.c:cache_grow()
>
> I agree and it is the same for mm/slab.c:fallback_alloc() but
> why is it not also required for mm/slab.c:slab_alloc_node()
> and mm/slab.c:slab_alloc() which both manipulate the local irqs?

Because cache_grow calls into the page allocator and we cannot do reclaim
with interrupts off.

--
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>