From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753985AbbBNK71 (ORCPT ); Sat, 14 Feb 2015 05:59:27 -0500 Received: from mx1.redhat.com ([209.132.183.28]:49278 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753795AbbBNK7Z (ORCPT ); Sat, 14 Feb 2015 05:59:25 -0500 Date: Sat, 14 Feb 2015 18:58:34 +0800 From: Baoquan He To: Joerg Roedel Cc: Ingo Molnar , Thomas Gleixner , "H. Peter Anvin" , Konrad Rzeszutek Wilk , x86@kernel.org, linux-kernel@vger.kernel.org, Joerg Roedel Subject: Re: [PATCH 0/3 v2] Fix kdump failures with crashkernel=high Message-ID: <20150214105834.GA7478@dhcp-17-102.nay.redhat.com> References: <1420555874-11506-1-git-send-email-joro@8bytes.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1420555874-11506-1-git-send-email-joro@8bytes.org> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org This patch is very helpful and necessary since several users complained about the failure caused by not enough low mem. And the default value 256M is suitable since the testing data showed it's sufficient now and should be save for a long time. And it also makes sense to supress the warning from buddy allocation failure which will call dump_stack in x86_swiotlb_alloc_coherent. Since it tried buddy allocation several times before the final try of bounce buffer allocation. So ack the whole patch set. Acked-by: Baoquan He Hi Joerg, Thanks for your effort on this issue. Could you please also update the cover letter or patch log to tell how 256M comes out with the later test result? I think it is convincing and helpful to understand. Thanks Baoquan On 01/06/15 at 03:51pm, Joerg Roedel wrote: > v1->v2: > > * Updated comments based on feedback from Konrad > * Added Acked-bys > * Rebased to v3.19-rc3 > > Hi, > > here is a patch-set to fix failed kdump kernel boots when > the systems was booted with crashkernel=X,high. On those > systems the kernel allocates only 72MiB of low-memory for > DMA buffers, which showed to be too low on some systems. > > The problem is that 64MiB of the low-memory is allocated by > swiotlb, leaving 8MB for the page-allocator. But swiotlb > tries to allocate DMA memory from the page-allocator first, > which fails pretty fast in the boot sequence, causing > warnings. This patch-set removes these warnings. > > But even the 64MiB for swiotlb are eaten up on some systems, > so that the default of low-memory allocated for the > crash-kernel is increase from 72MB to 256MB (only changing > the defaults, can still be overwritten by crashkernel=X,low). > > This number comes from experiments on the affected systems, > 128MiB low-memory was still not enough there, thus I set the > value to 256MiB to fix the issues. > > Any feedback appreciated. > > Thanks, > > Joerg > > Joerg Roedel (3): > swiotlb: Warn on allocation failure in swiotlb_alloc_coherent > x86, swiotlb: Try coherent allocations with __GFP_NOWARN > x86, crash: Allocate enough low-mem when crashkernel=high > > arch/x86/kernel/pci-swiotlb.c | 8 ++++++++ > arch/x86/kernel/setup.c | 5 ++++- > lib/swiotlb.c | 11 +++++++++-- > 3 files changed, 21 insertions(+), 3 deletions(-) > > -- > 1.9.1 > > Joerg Roedel (3): > swiotlb: Warn on allocation failure in swiotlb_alloc_coherent > x86, swiotlb: Try coherent allocations with __GFP_NOWARN > x86, crash: Allocate enough low-mem when crashkernel=high > > arch/x86/kernel/pci-swiotlb.c | 8 ++++++++ > arch/x86/kernel/setup.c | 5 ++++- > lib/swiotlb.c | 11 +++++++++-- > 3 files changed, 21 insertions(+), 3 deletions(-) > > -- > 1.9.1 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/