linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
* Does iommu_init_table need to use GFP_ATOMIC allocations?
@ 2013-09-19 16:50 Nishanth Aravamudan
  2013-10-01  4:09 ` Michael Ellerman
  0 siblings, 1 reply; 2+ messages in thread
From: Nishanth Aravamudan @ 2013-09-19 16:50 UTC (permalink / raw)
  To: Benjamin Herrenschmidt
  Cc: Paul Mackerras, linuxppc-dev, Thadeu Lima de Souza Cascardo,
	Anton Blanchard

Under heavy (DLPAR?) stress, we tripped this panic() in
arch/powerpc/kernel/iommu.c::iommu_init_table():

        page = alloc_pages_node(nid, GFP_ATOMIC, get_order(sz));
        if (!page)
                panic("iommu_init_table: Can't allocate %ld bytes\n",
sz);

Before the panic() we got a page allocation failure for an order-2
allocation. There appears to be memory free, but perhaps not in the
ATOMIC context. I looked through all the call-sites of
iommu_init_table() and didn't see any obvious reason to need an ATOMIC
allocation. Most call-sites in fact have an explicit GFP_KERNEL
allocation shortly before the call to iommu_init_table(), indicating we
are not in an atomic context. There is some indirection for some paths,
but I didn't see any locks indicating that GFP_KERNEL is inappropriate.
Does anyone know if/why ATOMIC allocations are necessary here?

Thanks,
Nish

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: Does iommu_init_table need to use GFP_ATOMIC allocations?
  2013-09-19 16:50 Does iommu_init_table need to use GFP_ATOMIC allocations? Nishanth Aravamudan
@ 2013-10-01  4:09 ` Michael Ellerman
  0 siblings, 0 replies; 2+ messages in thread
From: Michael Ellerman @ 2013-10-01  4:09 UTC (permalink / raw)
  To: Nishanth Aravamudan
  Cc: Paul Mackerras, linuxppc-dev, Anton Blanchard,
	Thadeu Lima de Souza Cascardo

On Thu, Sep 19, 2013 at 09:50:35AM -0700, Nishanth Aravamudan wrote:
> Under heavy (DLPAR?) stress, we tripped this panic() in
> arch/powerpc/kernel/iommu.c::iommu_init_table():
> 
>         page = alloc_pages_node(nid, GFP_ATOMIC, get_order(sz));
>         if (!page)
>                 panic("iommu_init_table: Can't allocate %ld bytes\n",
> sz);
> 
> Before the panic() we got a page allocation failure for an order-2
> allocation. There appears to be memory free, but perhaps not in the
> ATOMIC context. I looked through all the call-sites of
> iommu_init_table() and didn't see any obvious reason to need an ATOMIC
> allocation. Most call-sites in fact have an explicit GFP_KERNEL
> allocation shortly before the call to iommu_init_table(), indicating we
> are not in an atomic context. There is some indirection for some paths,
> but I didn't see any locks indicating that GFP_KERNEL is inappropriate.
> Does anyone know if/why ATOMIC allocations are necessary here?

I can't see any reason for it.

It was GFP_ATOMIC in the initial ppc64 code submission, so there's no
explanation in the commit history for it.

cheers

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2013-10-01  4:09 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-09-19 16:50 Does iommu_init_table need to use GFP_ATOMIC allocations? Nishanth Aravamudan
2013-10-01  4:09 ` Michael Ellerman

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).