Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 23 Apr 2015 12:49:51 -0600
From:      Scott Long <scott4long@yahoo.com>
To:        Dmitry Chagin <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:  <4E109480-FD27-4C7F-8B5F-B1DB2232CD3D@yahoo.com>
In-Reply-To: <5B48434B-EA97-45B3-BC4E-B039A868186B@yahoo.com>
References:  <201504120621.t3C6LxAV095209@svn.freebsd.org> <5B48434B-EA97-45B3-BC4E-B039A868186B@yahoo.com>

next in thread | previous in thread | raw e-mail | index | archive | help


> On Apr 23, 2015, at 6:19 AM, Scott Long <scott4long@yahoo.com> wrote:
> 
>> 
>> On Apr 12, 2015, at 12:21 AM, Dmitry Chagin <dchagin@FreeBSD.org> 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.

Scott





Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4E109480-FD27-4C7F-8B5F-B1DB2232CD3D>