From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from psmtp.com (na3sys010amx171.postini.com [74.125.245.171]) by kanga.kvack.org (Postfix) with SMTP id 32F236B006C for ; Fri, 11 Jan 2013 10:38:27 -0500 (EST) Date: Fri, 11 Jan 2013 16:38:23 +0100 From: Michal Hocko Subject: Re: mmots: memory-hotplug: implement register_page_bootmem_info_section of sparse-vmemmap fix Message-ID: <20130111153823.GK7286@dhcp22.suse.cz> References: <20130111095658.GC7286@dhcp22.suse.cz> <20130111101745.GD7286@dhcp22.suse.cz> <20130111102924.GE7286@dhcp22.suse.cz> <20130111104759.GF7286@dhcp22.suse.cz> <50F00041.2040305@cn.fujitsu.com> <20130111121226.GI7286@dhcp22.suse.cz> <50F007C9.10606@cn.fujitsu.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50F007C9.10606@cn.fujitsu.com> Sender: owner-linux-mm@kvack.org List-ID: To: Tang Chen Cc: Andrew Morton , Wen Congyang , Yasuaki Ishimatsu , Wu Jianguo , KOSAKI Motohiro , Jiang Liu , Kamezawa Hiroyuki , Lai Jiangshan , Ingo Molnar , Thomas Gleixner , "H. Peter Anvin" , linux-mm@kvack.org, LKML On Fri 11-01-13 20:38:33, Tang Chen wrote: > On 01/11/2013 08:12 PM, Michal Hocko wrote: > >On Fri 11-01-13 20:06:25, Tang Chen wrote: > >>On 01/11/2013 06:47 PM, Michal Hocko wrote: > >>>> > >>>>Darn! And now that I am looking at the patch closer it is too x86 > >>>>centric so this cannot be in the generic code. I will try to cook > >>>>something better. Sorry about the noise. > >>> > >>>It is more complicated than I thought. One would tell it's a mess. > >>>The patch bellow fixes the compilation issue but I am not sure we want > >>>to include memory_hotplug.h into arch/x86/mm/init_64.c. Moreover > >>> > >>>+void register_page_bootmem_memmap(unsigned long section_nr, > >>>+ struct page *start_page, unsigned long size) > >>>+{ > >>>+ /* TODO */ > >>>+} > >>> > >>>for other archs would suggest that the code is not ready yet. Should > >>>this rather be dropped for now? > >> > >>Hi Michal, > >> > >>Do you mean remove register_page_bootmem_memmap() from other > >>architectures ? > > > >No I meant the patch to be dropped until it gets implementation for > >other architectures or the users of the function would be explicit about > >archs which are supported. What happens if the implementation is empty > >will the generic code work properly? From my very limitted understanding > >of the code it won't. > > Hi Michal, > > Hum, I see. Thank you for your remind. :) > register_page_bootmem_info_section() will be different in other > architectures if register_page_bootmem_memmap() is empty. Not sure I understand what "different" means here but I suspect it would be buggy. Is that correct? > I think we can post a patch to make register_page_bootmem_info_section() > the same as before, and we just implement the x86 version first. So that > it will have no harm to other architectures. I haven't followed the previous versions of the patch - I have noticed this being broken only because it failed during my automatic build testing when merging new mmots tree into mm git tree. I have no objections for further patches of course but this one seems to be buggy so it should be dropped until a fixed version is available. > How do you think ? > > Thanks. :) > > > > -- Michal Hocko SUSE Labs -- 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