[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5283EBCD.6070305@zytor.com>
Date: Wed, 13 Nov 2013 13:14:53 -0800
From: "H. Peter Anvin" <hpa@...or.com>
To: Vivek Goyal <vgoyal@...hat.com>,
linux kernel mailing list <linux-kernel@...r.kernel.org>,
HATAYAMA Daisuke <d.hatayama@...fujitsu.com>
CC: Kexec Mailing List <kexec@...ts.infradead.org>,
Baoquan He <bhe@...hat.com>, WANG Chao <chaowang@...hat.com>,
Dave Young <dyoung@...hat.com>,
"Eric W. Biederman" <ebiederm@...ssion.com>
Subject: Re: /proc/vmcore mmap() failure issue
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists