From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757472AbZBLB2l (ORCPT ); Wed, 11 Feb 2009 20:28:41 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1756232AbZBLB2d (ORCPT ); Wed, 11 Feb 2009 20:28:33 -0500 Received: from mga09.intel.com ([134.134.136.24]:7178 "EHLO mga09.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756191AbZBLB2c (ORCPT ); Wed, 11 Feb 2009 20:28:32 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.38,194,1233561600"; d="scan'208";a="386092632" Subject: Re: specjbb2005 fails with 2.6.29-rc4 From: "Zhang, Yanmin" To: Lin Ming Cc: torvalds@linux-foundation.org, linux-kernel In-Reply-To: <1234401644.7699.33.camel@minggr.sh.intel.com> References: <1234401390.7699.29.camel@minggr.sh.intel.com> <1234401644.7699.33.camel@minggr.sh.intel.com> Content-Type: text/plain Date: Thu, 12 Feb 2009 09:28:17 +0800 Message-Id: <1234402097.2604.376.camel@ymzhang> Mime-Version: 1.0 X-Mailer: Evolution 2.22.1 (2.22.1-2.fc9) Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 2009-02-12 at 09:20 +0800, Lin Ming wrote: > On Thu, 2009-02-12 at 09:16 +0800, Lin Ming wrote: > > specjbb2005 fails with 2.6.29-rc4 in many testing machines. > > > > On a 4*4cores Tigerton machine, run specjb2005 with > > starting_number_warehouses = 1 and ending_number_warehouses = 34. > > It fails when warehouses=16. > > > > Test with Jrockit VM fails. And it works well if OpenJDK is used > > instead. One difference between Jrockit and OpenJDK is Jrokit uses huge pages. > > Bisect locates below commit. > > > > > commit fc8744adc870a8d4366908221508bb113d8b72ee > > Author: Linus Torvalds > > Date: Sat Jan 31 15:08:56 2009 -0800 > > > > Stop playing silly games with the VM_ACCOUNT flag > > > > The mmap_region() code would temporarily set the VM_ACCOUNT flag for > > anonymous shared mappings just to inform shmem_zero_setup() that it > > should enable accounting for the resulting shm object. It would then > > clear the flag after calling ->mmap (for the /dev/zero case) or doing > > shmem_zero_setup() (for the MAP_ANON case). > > > > This just resulted in vma merge issues, but also made for just > > unnecessary confusion. Use the already-existing VM_NORESERVE flag for > > this instead, and let shmem_{zero|file}_setup() just figure it out from > > that. > > > > This also happens to make it obvious that the new DRI2 GEM layer uses a > > non-reserving backing store for its object allocation - which is quite > > possibly not intentional. But since I didn't want to change semantics > > in this patch, I left it alone, and just updated the caller to use the > > new flag semantics. > > > > Signed-off-by: Linus Torvalds > > --- > > drivers/gpu/drm/drm_gem.c | 2 +- > > ipc/shm.c | 4 +- > > mm/mmap.c | 48 +++++++++++++++++++++++--------------------- > > mm/shmem.c | 2 +- > > 4 files changed, 29 insertions(+), 27 deletions(-) > > >