From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: multipart/mixed; boundary="===============5599915754436128487==" MIME-Version: 1.0 From: Huang Ying To: lkp@lists.01.org Subject: Re: [rhashtable] 9d901bc0515: WARNING: CPU: 0 PID: 1 at arch/x86/mm/ioremap.c:63 __ioremap_check_ram+0x6a/0x99() Date: Fri, 21 Aug 2015 15:09:42 +0800 Message-ID: <1440140982.8683.32.camel@intel.com> In-Reply-To: <20150821064207.GA5835@gondor.apana.org.au> List-Id: --===============5599915754436128487== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On Fri, 2015-08-21 at 14:42 +0800, Herbert Xu wrote: > On Fri, Aug 21, 2015 at 02:05:19PM +0800, kernel test robot wrote: > > FYI, we noticed the below changes on > > = > > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git = > > master > > commit 9d901bc05153bbf33b5da2cd6266865e531f0545 ("rhashtable: Free = > > bucket tables asynchronously after rehash") > > = > > With the commit, the possibility of OOM is increased under our boot = > > testing. > = > Can you gather some stats on how much memory rhashtable is actually > using? With that kernel you've probably got only one rhashtable user > which is netlink. > = > Bear in mind that this is a fairly low-memory machine (< 300M) so > it's not clear to me that this patch is the root cause of your OOM > problem. Sorry, my fault. There are OOM for parent commit too, just some dmesg difference, which I miss understood. Please ignore this report. I will be more careful next time. Best Regards, Huang, Ying --===============5599915754436128487==-- From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752228AbbHUHJq (ORCPT ); Fri, 21 Aug 2015 03:09:46 -0400 Received: from mga11.intel.com ([192.55.52.93]:23107 "EHLO mga11.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751019AbbHUHJo (ORCPT ); Fri, 21 Aug 2015 03:09:44 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.15,720,1432623600"; d="scan'208";a="788057076" Message-ID: <1440140982.8683.32.camel@intel.com> Subject: Re: [lkp] [rhashtable] 9d901bc0515: WARNING: CPU: 0 PID: 1 at arch/x86/mm/ioremap.c:63 __ioremap_check_ram+0x6a/0x99() From: Huang Ying To: Herbert Xu Cc: lkp@01.org, LKML , "David S. Miller" , netdev@vger.kernel.org Date: Fri, 21 Aug 2015 15:09:42 +0800 In-Reply-To: <20150821064207.GA5835@gondor.apana.org.au> References: <87fv3dkwgw.fsf@yhuang-dev.intel.com> <20150821064207.GA5835@gondor.apana.org.au> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.16.3-1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 2015-08-21 at 14:42 +0800, Herbert Xu wrote: > On Fri, Aug 21, 2015 at 02:05:19PM +0800, kernel test robot wrote: > > FYI, we noticed the below changes on > > > > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git > > master > > commit 9d901bc05153bbf33b5da2cd6266865e531f0545 ("rhashtable: Free > > bucket tables asynchronously after rehash") > > > > With the commit, the possibility of OOM is increased under our boot > > testing. > > Can you gather some stats on how much memory rhashtable is actually > using? With that kernel you've probably got only one rhashtable user > which is netlink. > > Bear in mind that this is a fairly low-memory machine (< 300M) so > it's not clear to me that this patch is the root cause of your OOM > problem. Sorry, my fault. There are OOM for parent commit too, just some dmesg difference, which I miss understood. Please ignore this report. I will be more careful next time. Best Regards, Huang, Ying