[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <DA586906BA1FFC4384FCFD6429ECE860316C01EA@shzsmsx502.ccr.corp.intel.com>
Date: Tue, 12 Jan 2010 17:05:19 +0800
From: "Zheng, Shaohui" <shaohui.zheng@...el.com>
To: KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>
CC: "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>,
"ak@...ux.intel.com" <ak@...ux.intel.com>,
"y-goto@...fujitsu.com" <y-goto@...fujitsu.com>,
Dave Hansen <haveblue@...ibm.com>,
"x86@...nel.org" <x86@...nel.org>
Subject: RE: [ RESEND PATCH v3] Memory-Hotplug: Fix the bug on interface
/dev/mem for 64-bit kernel
>
> 3 points...
> 1. I think this patch cannot be compiled in archs other than x86. Right ?
> IOW, please add static inline dummy...
> [Zheng, Shaohui] Agree, I will add a static dummy function
>
> 2. pgdat->[start,end], totalram_pages etc...are updated at memory hotplug.
> Please place the hook nearby them.
> [Zheng, Shaohui] Agree.
>
> 3. I recommend you yo use memory hotplug notifier.
> If it's allowed, it will be cleaner.
> It seems there are no strict ordering to update parameters this patch touches.
>
> [Zheng, Shaohui] Kame, do you means put the hook into function slab_mem_going_online_callback, it seems a good idea. If we select this method, we will need not to update these variable in function add_memory explicitly.
>
yes. I think callback is the best.
[Zheng, Shaohui] it is okay for me, I will rewrite my patch and test it in local, thanks Kame :).
Thanks,
-Kame
Thanks & Regards,
Shaohui
--
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