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
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
