[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4B478BEA.1010504@linux.intel.com>
Date: Fri, 08 Jan 2010 20:47:54 +0100
From: Andi Kleen <ak@...ux.intel.com>
To: "H. Peter Anvin" <hpa@...nel.org>
CC: "Zheng, Shaohui" <shaohui.zheng@...el.com>,
"linux-mm@...ck.org" <linux-mm@...ck.org>,
"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"y-goto@...fujitsu.com" <y-goto@...fujitsu.com>,
Dave Hansen <haveblue@...ibm.com>,
"Wu, Fengguang" <fengguang.wu@...el.com>,
"x86@...nel.org" <x86@...nel.org>
Subject: Re: [PATCH - resend] Memory-Hotplug: Fix the bug on interface /dev/mem
for 64-bit kernel(v1)
H. Peter Anvin wrote:
> On 01/07/2010 07:32 PM, Zheng, Shaohui wrote:
>> Resend the patch to the mailing-list, the original patch URL is
>> http://patchwork.kernel.org/patch/69075/, it is not accepted without comments,
>> sent it again to review.
>>
>> Memory-Hotplug: Fix the bug on interface /dev/mem for 64-bit kernel
>>
>> The new added memory can not be access by interface /dev/mem, because we do not
>> update the variable high_memory. This patch add a new e820 entry in e820 table,
>> and update max_pfn, max_low_pfn and high_memory.
>>
>> We add a function update_pfn in file arch/x86/mm/init.c to udpate these
>> varibles. Memory hotplug does not make sense on 32-bit kernel, so we did not
>> concern it in this function.
>>
>
> Memory hotplug makes sense on 32-bit kernels, at least in virtual
> environments.
No VM currently supports it to my knowledge. They all use traditional
balooning.
If someone adds that they can still fix it, but right now fixing it on 64bit
is the important part.
-Andi
--
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