Date: Thu, 23 Apr 2015 23:26:55 -0600 From: Scott Long <scott4long@yahoo.com> To: Chagin Dmitry <dchagin@freebsd.org> 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: <FFE5F8D2-A15E-4087-93F5-3640662217DD@yahoo.com> In-Reply-To: <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> <20150423192819.GA13122@dchagin.static.corbina.net>
next in thread | previous in thread | raw e-mail | index | archive | help
> On Apr 23, 2015, at 1:28 PM, Chagin Dmitry <dchagin@freebsd.org> = wrote: >=20 > On Thu, Apr 23, 2015 at 12:49:51PM -0600, Scott Long wrote: >>=20 >>> On Apr 23, 2015, at 6:19 AM, Scott Long <scott4long@yahoo.com> = wrote: >>>=20 >>>>=20 >>>> On Apr 12, 2015, at 12:21 AM, Dmitry Chagin <dchagin@FreeBSD.org> = wrote: >>>>=20 >>>> Author: dchagin >>>> Date: Sun Apr 12 06:21:58 2015 >>>> New Revision: 281451 >>>> URL: https://svnweb.freebsd.org/changeset/base/281451 >>>>=20 >>>> Log: >>>> Rework r281162. Indeed, the flexible array member is preferable = here. >>>>=20 >>>> Suggested by: Justin T. Gibbs >>>>=20 >>>> MFC after: 3 days >>>>=20 >>>> Modified: >>>> head/sys/vm/uma_core.c >>>> head/sys/vm/uma_int.h >>>=20 >>> 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. >>>=20 >>=20 >> 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. >>=20 > 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. >=20 > I do not object to revert, but give me a chance to figure out what's = going on. With INVARIANTS enabled, the system will panic. Without it, it will = spin in vm_mem_init(), as you noted. Even if it=E2=80=99s not happening = to everyone, it=E2=80=99s a serious problem for such a minor anticipated = benefit. I must insist that it be reverted. Scott
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?FFE5F8D2-A15E-4087-93F5-3640662217DD>