From owner-svn-src-all@FreeBSD.ORG Thu Apr 23 19:29:39 2015 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 28A1D804; Thu, 23 Apr 2015 19:29:39 +0000 (UTC) Received: from heemeyer.club (heemeyer.club [IPv6:2001:19f0:6400:80a1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "heemeyer.club", Issuer "heemeyer.club" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id D72A0188C; Thu, 23 Apr 2015 19:29:37 +0000 (UTC) Received: from dchagin.static.corbina.net (dchagin.static.corbina.ru [78.107.232.239]) by heemeyer.club (8.15.1/8.15.1) with ESMTPS id t3NJSR8u019804 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 23 Apr 2015 19:29:27 GMT (envelope-from dchagin@dchagin.static.corbina.net) X-Authentication-Warning: heemeyer.club: Host dchagin.static.corbina.ru [78.107.232.239] claimed to be dchagin.static.corbina.net Received: from dchagin.static.corbina.net (localhost [127.0.0.1]) by dchagin.static.corbina.net (8.15.1/8.15.1) with ESMTPS id t3NJSJb8013214 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 23 Apr 2015 22:28:26 +0300 (MSK) (envelope-from dchagin@dchagin.static.corbina.net) Received: (from dchagin@localhost) by dchagin.static.corbina.net (8.15.1/8.15.1/Submit) id t3NJSJn7013213; Thu, 23 Apr 2015 22:28:19 +0300 (MSK) (envelope-from dchagin) Date: Thu, 23 Apr 2015 22:28:19 +0300 From: Chagin Dmitry To: Scott Long Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r281451 - head/sys/vm Message-ID: <20150423192819.GA13122@dchagin.static.corbina.net> References: <201504120621.t3C6LxAV095209@svn.freebsd.org> <5B48434B-EA97-45B3-BC4E-B039A868186B@yahoo.com> <4E109480-FD27-4C7F-8B5F-B1DB2232CD3D@yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E109480-FD27-4C7F-8B5F-B1DB2232CD3D@yahoo.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2015 19:29:39 -0000 On Thu, Apr 23, 2015 at 12:49:51PM -0600, Scott Long wrote: > > > On Apr 23, 2015, at 6:19 AM, Scott Long wrote: > > > >> > >> On Apr 12, 2015, at 12:21 AM, Dmitry Chagin wrote: > >> > >> Author: dchagin > >> Date: Sun Apr 12 06:21:58 2015 > >> New Revision: 281451 > >> URL: https://svnweb.freebsd.org/changeset/base/281451 > >> > >> Log: > >> Rework r281162. Indeed, the flexible array member is preferable here. > >> > >> Suggested by: Justin T. Gibbs > >> > >> MFC after: 3 days > >> > >> Modified: > >> head/sys/vm/uma_core.c > >> head/sys/vm/uma_int.h > > > > There???s still something wrong with this. I have a machine with 28 cores (56 with hyperthreading) and 256GB of RAM, and ever since you committed r281162, it panics early in boot with a failed assertion. It looks like the first few members of a uma_slab_t are getting overwritten accidentally, and somehow the padding of the extra member in the uma_zone_t was previously protecting it. I don???t know the exact cause yet, but I must ask that you revert to r281161 in HEAD and stable/10 until the problem is resolved. > > > > I think the problem is that the masterzone_k and masterzone_z objects that are statically allocated in uma_core.c no longer have space for the uz_cpu field, but uma_zalloc_arg() always assumes that it???s there. Early in boot when the ???kegs' and ???zones??? zones are being initialized, there???s only 1 CPU so pre-allocating 1 uz_cpu element in the uma_zone is enough. I can???t see any way around this without significantly changing how uma_zalloc_arg() treats per-cpu caches. I think it???s best to revert this change. > Hi, they initialized in uma_startup() and not used before. I have a private converstion with a man which stable/10 hangs in vm_mem_init().\ with my commit. weird. I do not object to revert, but give me a chance to figure out what's going on. -- Have fun! chd