* 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).