svn commit: r281451 - head/sys/vm

[Adrian Chadd]

On 23 April 2015 at 22:26, Scott Long <scott4long at yahoo.com> wrote:
>
>> On Apr 23, 2015, at 1:28 PM, Chagin Dmitry <dchagin at freebsd.org> wrote:
>>
>> On Thu, Apr 23, 2015 at 12:49:51PM -0600, Scott Long wrote:
>>>
>>>> On Apr 23, 2015, at 6:19 AM, Scott Long <scott4long at yahoo.com> wrote:
>>>>
>>>>>
>>>>> On Apr 12, 2015, at 12:21 AM, Dmitry Chagin <dchagin at 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.
>>>
>> 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.
>
> With INVARIANTS enabled, the system will panic.  Without it, it will spin in vm_mem_init(), as you noted.  Even if it’s not happening to everyone, it’s a serious problem for such a minor anticipated benefit.  I must insist that it be reverted.


Hi,

+1 - please revert the patch for now and figure it out locally. Having
-HEAD broken is very annoying.



-a