From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pb0-f42.google.com (mail-pb0-f42.google.com [209.85.160.42]) by kanga.kvack.org (Postfix) with ESMTP id E0C6A6B0031 for ; Mon, 18 Nov 2013 22:02:32 -0500 (EST) Received: by mail-pb0-f42.google.com with SMTP id uo5so7699933pbc.29 for ; Mon, 18 Nov 2013 19:02:32 -0800 (PST) Received: from psmtp.com ([74.125.245.155]) by mx.google.com with SMTP id yg5si10994833pbc.86.2013.11.18.19.02.30 for ; Mon, 18 Nov 2013 19:02:31 -0800 (PST) Received: by mail-ie0-f181.google.com with SMTP id e14so3503172iej.12 for ; Mon, 18 Nov 2013 19:02:29 -0800 (PST) MIME-Version: 1.0 In-Reply-To: <528ABFA3.6060905@zytor.com> References: <20131114180455.GA32212@anatevka.fc.hp.com> <20131115005049.GJ5116@anatevka.fc.hp.com> <20131115062417.GB9237@gmail.com> <5285C639.5040203@zytor.com> <20131115140738.GB6637@redhat.com> <52865CA1.5020309@zytor.com> <20131115183002.GE6637@redhat.com> <528ABFA3.6060905@zytor.com> Date: Mon, 18 Nov 2013 19:02:29 -0800 Message-ID: Subject: Re: [PATCH 0/3] Early use of boot service memory From: Yinghai Lu Content-Type: text/plain; charset=ISO-8859-1 Sender: owner-linux-mm@kvack.org List-ID: To: "H. Peter Anvin" Cc: Vivek Goyal , Ingo Molnar , jerry.hoemann@hp.com, Pekka Enberg , Rob Landley , Thomas Gleixner , Ingo Molnar , x86 maintainers , Matt Fleming , Andrew Morton , "list@ebiederm.org:DOCUMENTATION" , "list@ebiederm.org:MEMORY MANAGEMENT" , linux-efi@vger.kernel.org, LKML On Mon, Nov 18, 2013 at 5:32 PM, H. Peter Anvin wrote: > On 11/15/2013 10:30 AM, Vivek Goyal wrote: >> >> And IOMMU support is very flaky with kdump. And IOMMU's can be turned >> off at command line. And that would force one to remove crahkernel_low=0. >> So change of one command line option forces change of another. It is >> complicated. >> >> Also there are very few systems which work with IOMMU on. A lot more >> which work without IOMMU. We have all these DMAR issues and still nobody >> has been able to address IOMMU issues properly. >> > > Why do we need such a big bounce buffer for kdump swiotlb anyway? > Surely the vast majority of all dump devices don't need it, so it is > there for completeness, no? Yes, because normal path will need that 64M+32k default. We may reduce that amount to 16M or 18M and in second kernel let allocate less for swiotlb. Thanks Yinghai -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org