From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from terminus.zytor.com ([2001:1868:205::10] helo=mail.zytor.com) by merlin.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1VghmW-0005XK-Q6 for kexec@lists.infradead.org; Wed, 13 Nov 2013 21:15:25 +0000 Message-ID: <5283EBCD.6070305@zytor.com> Date: Wed, 13 Nov 2013 13:14:53 -0800 From: "H. Peter Anvin" MIME-Version: 1.0 Subject: Re: /proc/vmcore mmap() failure issue References: <20131113204130.GD7613@redhat.com> <20131113210432.GE7613@redhat.com> In-Reply-To: <20131113210432.GE7613@redhat.com> List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "kexec" Errors-To: kexec-bounces+dwmw2=twosheds.infradead.org@lists.infradead.org To: Vivek Goyal , linux kernel mailing list , HATAYAMA Daisuke Cc: Dave Young , Kexec Mailing List , WANG Chao , Baoquan He , "Eric W. Biederman" On 11/13/2013 01:04 PM, Vivek Goyal wrote: > [CC hpa ] > > And this issue brings me to the question that why do we allow sytem RAM > ranges which do not start on page boundary or do not end on page boundary. > Can't we truncate the BIOS reported RAM ranges in such a way so that > they start and end at PAGE boundary and rest of the kernel will never see > unaligned portion of RAM and this will make life so much simpler for > other tools. > That is a bit of a headache for doing in the memblock space. We do, in fact, truncate partial pages, but later in the game. It is possible we should push that sooner in the stack. The fact that it makes into the rbtrees is fishy, but it also makes me wonder if we're doing something totally stupid with regards to the memory mappings -- if this means we're mapping ACPI data as noncacheable, that is not just a performance problem but just plain wrong. I don't even think the MTRRs can represent different caching attributes for different parts of a page, so this is something that we are doing. -hpa _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751352Ab3KMVPi (ORCPT ); Wed, 13 Nov 2013 16:15:38 -0500 Received: from terminus.zytor.com ([198.137.202.10]:56024 "EHLO mail.zytor.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750981Ab3KMVP3 (ORCPT ); Wed, 13 Nov 2013 16:15:29 -0500 Message-ID: <5283EBCD.6070305@zytor.com> Date: Wed, 13 Nov 2013 13:14:53 -0800 From: "H. Peter Anvin" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Vivek Goyal , linux kernel mailing list , HATAYAMA Daisuke CC: Kexec Mailing List , Baoquan He , WANG Chao , Dave Young , "Eric W. Biederman" Subject: Re: /proc/vmcore mmap() failure issue References: <20131113204130.GD7613@redhat.com> <20131113210432.GE7613@redhat.com> In-Reply-To: <20131113210432.GE7613@redhat.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 11/13/2013 01:04 PM, Vivek Goyal wrote: > [CC hpa ] > > And this issue brings me to the question that why do we allow sytem RAM > ranges which do not start on page boundary or do not end on page boundary. > Can't we truncate the BIOS reported RAM ranges in such a way so that > they start and end at PAGE boundary and rest of the kernel will never see > unaligned portion of RAM and this will make life so much simpler for > other tools. > That is a bit of a headache for doing in the memblock space. We do, in fact, truncate partial pages, but later in the game. It is possible we should push that sooner in the stack. The fact that it makes into the rbtrees is fishy, but it also makes me wonder if we're doing something totally stupid with regards to the memory mappings -- if this means we're mapping ACPI data as noncacheable, that is not just a performance problem but just plain wrong. I don't even think the MTRRs can represent different caching attributes for different parts of a page, so this is something that we are doing. -hpa