From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758028AbYDRGta (ORCPT ); Fri, 18 Apr 2008 02:49:30 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753592AbYDRGtW (ORCPT ); Fri, 18 Apr 2008 02:49:22 -0400 Received: from fgwmail6.fujitsu.co.jp ([192.51.44.36]:52721 "EHLO fgwmail6.fujitsu.co.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752857AbYDRGtV (ORCPT ); Fri, 18 Apr 2008 02:49:21 -0400 Date: Fri, 18 Apr 2008 15:47:53 +0900 From: KAMEZAWA Hiroyuki To: Shi Weihua Cc: Andrew Morton , balbir@linux.vnet.ibm.com, xemul@openvz.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, hugh@veritas.com Subject: Re: [PATCH] memcgroup: check and initialize page->cgroup in memmap_init_zone Message-Id: <20080418154753.6a28a910.kamezawa.hiroyu@jp.fujitsu.com> In-Reply-To: <48083506.7080909@cn.fujitsu.com> References: <48080706.50305@cn.fujitsu.com> <48080930.5090905@cn.fujitsu.com> <48080B86.7040200@cn.fujitsu.com> <20080417201432.36b1c326.akpm@linux-foundation.org> <20080418123256.da4d1db0.kamezawa.hiroyu@jp.fujitsu.com> <20080418140946.e265c1f3.kamezawa.hiroyu@jp.fujitsu.com> <48083506.7080909@cn.fujitsu.com> Organization: Fujitsu X-Mailer: Sylpheed 2.4.2 (GTK+ 2.10.11; i686-pc-mingw32) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 18 Apr 2008 13:43:34 +0800 Shi Weihua wrote: > KAMEZAWA Hiroyuki wrote:: > > On Fri, 18 Apr 2008 12:32:56 +0900 > > KAMEZAWA Hiroyuki wrote: > > > >>> Or perhaps that page was used and then later freed before we got to > >>> memmap_init_zone() and was freed with a non-zero ->page_cgroup. Which is > >>> unlikely given that page.page_cgroup was only just added and is only > >>> present if CONFIG_CGROUP_MEM_RES_CTLR. > >>> > >> Hmm, I'll try his .config and see what happens. > >> > > I reproduced the hang with his config and confirmed his fix works well. > > But I can't find why...I'll dig a bit more. > > If i use CONFIG_SPARSEMEM instead of CONFIG_DISCONTIGMEM, the kernel > boots successfully. > AKAICT, CONFIG_DISCONTIGMEM + 64KB page -> hang --------------(*) CONFIG_SPRASEMEM_VMEMMAP + 64KB page -> works well CONFIG_DISCONTIGMEM + 16KB page -> works well CONFIG_SPARSEMEM_VMEMMAP + 16KB page -> works well CONFIG_DISCONTIGMEM + 64KB page + your patch -> works well Hmm. maybe memmap(and all possible bootmem) isn't cleared well in case (*). still chasing it. Thanks, -Kame