Re: Reboot while booting with new per-CPU allocator

From: Eric Anderson <anderson_at_centtech.com>
Date: Fri, 17 Jun 2005 06:32:16 -0500
Robert Watson wrote:
> 
> On Thu, 16 Jun 2005, Robert Watson wrote:
> 
>>> Great :) It did the trick. The laptop is happily booting with the new 
>>> allocator now. Thanks a lot to you and Alan Cox.
>>
>>
>> Looks like what basically happened is this these kern_malloc.c changes 
>> increase the memory burden on UMA as statistics structures for malloc 
>> types now get allocated from UMA.  It looks like, from your dmesg, you 
>> have a fair number of modules loaded, so the storage for the 
>> statistics comes out of the early UMA page pool, whereas before it 
>> came out of BSS. We'll see if further tuning is required or not with 
>> large numbers of modules.  The thing that surprised me, though, is the 
>> unclean failure mode.  The other report saw a clean panic which 
>> presumably made debugging it much easier...
> 
> 
> Interestingly, there's been a bunch of reports of this in the past few 
> days, and there weren't immediately after the malloc commit.  I wonder 
> if some other recent change has increased the amount of UMA memory 
> allocated early in the boot, increasing the level of reports...

alc         2005-06-16 17:06:34 UTC

   FreeBSD src repository

   Modified files:
     sys/vm               uma_int.h
   Log:
   Increase UMA_BOOT_PAGES to prevent a crash during initialization.  See
   http://docs.FreeBSD.org/cgi/mid.cgi?42AD8270.8060906 for a detailed
   description of the crash.

   Reported by: Eric Anderson
   Approved by: re (scottl)
   MFC after: 3 days

   Revision  Changes    Path
   1.31      +1 -1      src/sys/vm/uma_int.h


Eric





-- 
------------------------------------------------------------------------
Eric Anderson        Sr. Systems Administrator        Centaur Technology
A lost ounce of gold may be found, a lost moment of time never.
------------------------------------------------------------------------
Received on Fri Jun 17 2005 - 09:32:21 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:36 UTC