LKML Archive on lore.kernel.org help / color / mirror / Atom feed
From: Joerg Roedel <joro@8bytes.org> To: Ingo Molnar <mingo@redhat.com>, Thomas Gleixner <tglx@linutronix.de>, "H. Peter Anvin" <hpa@zytor.com>, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Cc: x86@kernel.org, linux-kernel@vger.kernel.org, Joerg Roedel <jroedel@suse.de>, Joerg Roedel <joro@8bytes.org> Subject: [PATCH 2/3] x86, swiotlb: Try coherent allocations with __GFP_NOWARN Date: Tue, 6 Jan 2015 15:51:13 +0100 [thread overview] Message-ID: <1420555874-11506-3-git-send-email-joro@8bytes.org> (raw) In-Reply-To: <1420555874-11506-1-git-send-email-joro@8bytes.org> From: Joerg Roedel <jroedel@suse.de> When we boot a kdump kernel in high memory, there is by default only 72MB of low memory available. The swiotlb code takes 64MB of it (by default) so that there are only 8MB left to allocate from. On systems with many devices this causes page allocator warnings from dma_generic_alloc_coherent(): systemd-udevd: page allocation failure: order:0, mode:0x280d4 CPU: 0 PID: 197 Comm: systemd-udevd Tainted: G W 3.12.28-4-default #1 Hardware name: HP ProLiant DL980 G7, BIOS P66 07/30/2012 ffff8800781335e0 ffffffff8150b1db 00000000000280d4 ffffffff8113af90 0000000000000000 0000000000000000 ffff88007efdbb00 0000000100000000 0000000000000000 0000000000000000 0000000000000000 0000000000000001 Call Trace: [<ffffffff8100467d>] dump_trace+0x7d/0x2d0 [<ffffffff81004964>] show_stack_log_lvl+0x94/0x170 [<ffffffff81005d91>] show_stack+0x21/0x50 [<ffffffff8150b1db>] dump_stack+0x41/0x51 [<ffffffff8113af90>] warn_alloc_failed+0xf0/0x160 [<ffffffff8150763a>] __alloc_pages_slowpath+0x72f/0x796 [<ffffffff8113ee7a>] __alloc_pages_nodemask+0x1ea/0x210 [<ffffffff81008256>] dma_generic_alloc_coherent+0x96/0x140 [<ffffffff8103fccc>] x86_swiotlb_alloc_coherent+0x1c/0x50 [<ffffffffa048ae5b>] ttm_dma_pool_alloc_new_pages+0xab/0x320 [ttm] [<ffffffffa048bc6e>] ttm_dma_populate+0x3ce/0x640 [ttm] [<ffffffffa0486>] ttm_tt_bind+0x36/0x60 [ttm] [<ffffffffa0484faf>] ttm_bo_handle_move_mem+0x55f/0x5c0 [ttm] [<ffffffffa0485be5>] ttm_bo_move_buffer+0x105/0x130 [ttm] [<ffffffffa0485cd1>] ttm_bo_validate+0xc1/0x130 [ttm] [<ffffffffa0485f8b>] ttm_bo_init+0x24b/0x400 [ttm] [<ffffffffa054f8bc>] radeon_bo_create+0x16c/0x200 [radeon] [<ffffffffa0563c8e>] radeon_ring_init+0x11e/0x2b0 [radeon] [<ffffffffa056c143>] r100_cp_init+0x123/0x5b0 [radeon] [<ffffffffa056e8e4>] r100_startup+0x194/0x230 [radeon] [<ffffffffa056ece3>] r100_init+0x223/0x410 [radeon] [<ffffffffa053495f>] radeon_device_init+0x6af/0x830 [radeon] [<ffffffffa0536979>] radeon_driver_load_kms+0x89/0x180 [radeon] [<ffffffffa04eeb31>] drm_get_pci_dev+0x121/0x2f0 [drm] [<ffffffff812d3ec9>ocal_pci_probe+0x39/0x60 [<ffffffff812d51e9>] pci_device_probe+0xa9/0x120 [<ffffffff8139871d>] driver_probe_device+0x9d/0x3d0 [<ffffffff81398b1b>] __driver_attach+0x8b/0x90 [<ffffffff8139667b>] bus_for_each_dev+0x5b/0x90 [<ffffffff81397cd8>] bus_add_driver+0x1f8/0x2c0 [<ffffffff8139911b>] driver_register+0x5b/0xe0 [<ffffffff810002c2>] do_one_initcall+0xf2/0x1a0 [<ffffffff810c8837>] load_module+0x1207/0x1c70 [<ffffffff810c93f5>] SYSC_finit_module+0x75/0xa0 [<ffffffff81519329>] system_call_fastpath+0x16/0x1b [<00007fac533d2789>] 0x7fac533d2788 After these warnings the code enters a fall-back path and allocated directly from the swiotlb aperture in the end. So remove these warnings as this is not a fatal error. Signed-off-by: Joerg Roedel <jroedel@suse.de> --- arch/x86/kernel/pci-swiotlb.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/arch/x86/kernel/pci-swiotlb.c b/arch/x86/kernel/pci-swiotlb.c index 77dd0ad..79b2291 100644 --- a/arch/x86/kernel/pci-swiotlb.c +++ b/arch/x86/kernel/pci-swiotlb.c @@ -20,6 +20,14 @@ void *x86_swiotlb_alloc_coherent(struct device *hwdev, size_t size, { void *vaddr; + /* + * When booting a kdump kernel in high memory these allocations are very + * likely to fail, as there are by default only 8MB of low memory to + * allocate from. So disable the warnings from the allocator when this + * happens. SWIOTLB also implements fall-backs for failed allocations. + */ + flags |= __GFP_NOWARN; + vaddr = dma_generic_alloc_coherent(hwdev, size, dma_handle, flags, attrs); if (vaddr) -- 1.9.1
next prev parent reply other threads:[~2015-01-06 14:51 UTC|newest] Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top 2015-01-06 14:51 [PATCH 0/3 v2] Fix kdump failures with crashkernel=high Joerg Roedel 2015-01-06 14:51 ` [PATCH 1/3] swiotlb: Warn on allocation failure in swiotlb_alloc_coherent Joerg Roedel 2015-01-23 17:04 ` Borislav Petkov 2015-01-26 11:49 ` Joerg Roedel 2015-01-06 14:51 ` Joerg Roedel [this message] 2015-01-23 17:03 ` [PATCH 2/3] x86, swiotlb: Try coherent allocations with __GFP_NOWARN Borislav Petkov 2015-01-26 3:22 ` Baoquan He 2015-01-26 11:54 ` Joerg Roedel 2015-01-06 14:51 ` [PATCH 3/3] x86, crash: Allocate enough low-mem when crashkernel=high Joerg Roedel 2015-01-23 8:44 ` Baoquan He 2015-01-26 12:07 ` Joerg Roedel 2015-02-01 8:41 ` Baoquan He 2015-02-04 14:10 ` Joerg Roedel 2015-02-09 12:20 ` Joerg Roedel 2015-02-13 15:34 ` Baoquan He 2015-02-13 22:28 ` Joerg Roedel 2015-02-14 11:44 ` Baoquan He 2015-01-23 17:02 ` Borislav Petkov 2015-01-26 12:11 ` Joerg Roedel 2015-01-26 12:20 ` Borislav Petkov 2015-01-26 12:40 ` Joerg Roedel 2015-01-26 12:45 ` Borislav Petkov 2015-01-14 13:35 ` [PATCH 0/3 v2] Fix kdump failures with crashkernel=high Joerg Roedel 2015-01-19 19:26 ` Borislav Petkov 2015-02-14 10:58 ` Baoquan He 2015-02-14 16:11 ` Joerg Roedel 2015-06-02 8:54 ` Baoquan He 2015-06-02 9:08 ` Joerg Roedel -- strict thread matches above, loose matches on Subject: below -- 2015-06-05 10:29 [PATCH 0/3 v3] " Joerg Roedel 2015-06-05 10:30 ` [PATCH 2/3] x86, swiotlb: Try coherent allocations with __GFP_NOWARN Joerg Roedel 2014-11-28 11:29 [PATCH 0/3] Fix kdump failures with crashkernel=high Joerg Roedel 2014-11-28 11:29 ` [PATCH 2/3] x86, swiotlb: Try coherent allocations with __GFP_NOWARN Joerg Roedel 2014-12-01 20:28 ` Konrad Rzeszutek Wilk 2014-12-02 14:45 ` Joerg Roedel 2014-12-02 18:46 ` Konrad Rzeszutek Wilk 2014-12-03 10:27 ` Joerg Roedel
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=1420555874-11506-3-git-send-email-joro@8bytes.org \ --to=joro@8bytes.org \ --cc=hpa@zytor.com \ --cc=jroedel@suse.de \ --cc=konrad.wilk@oracle.com \ --cc=linux-kernel@vger.kernel.org \ --cc=mingo@redhat.com \ --cc=tglx@linutronix.de \ --cc=x86@kernel.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
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).