Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 24 Aug 2012 18:54:28 +0200
From:      Luigi Rizzo <rizzo@iet.unipi.it>
To:        Alan Cox <alc@rice.edu>
Cc:        alc@freebsd.org, current@freebsd.org
Subject:   Re: less aggressive contigmalloc ?
Message-ID:  <20120824165428.GA17495@onelab2.iet.unipi.it>
In-Reply-To: <5037A803.6030100@rice.edu>
References:  <20120822120105.GA63763@onelab2.iet.unipi.it> <CAJUyCcPOte19TJXpCVAskhf%2BDia_Zg5uj6J_idW67rGsOLaZXw@mail.gmail.com> <20120823163145.GA3999@onelab2.iet.unipi.it> <50366398.2070700@rice.edu> <20120823174504.GB4820@onelab2.iet.unipi.it> <50371485.1020409@rice.edu> <20120824145708.GA16557@onelab2.iet.unipi.it> <5037A803.6030100@rice.edu>

next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Aug 24, 2012 at 11:12:51AM -0500, Alan Cox wrote:
> On 08/24/2012 09:57, Luigi Rizzo wrote:
> >On Fri, Aug 24, 2012 at 12:43:33AM -0500, Alan Cox wrote:
> >>On 08/23/2012 12:45, Luigi Rizzo wrote:
> >>>On Thu, Aug 23, 2012 at 12:08:40PM -0500, Alan Cox wrote:
> >>>...
> >>>>>yes i do see that.
> >>>>>
> >>>>>Maybe less aggressive with M_NOWAIT but still kills processes.
> >>>>Are you compiling world with MALLOC_PRODUCTION?  The latest version of
> >>>whatever the default is. But:
> >>>
> >>>>jemalloc uses significantly more memory when debugging options are
> >>>>enabled.  This first came up in a thread titled "10-CURRENT and swap
> >>>>usage" back in June.
> >>>>
> >>>>Even at its most aggressive, M_WAITOK, contigmalloc() does not directly
> >>>>kill processes.  If process death coincides with the use of
> >>>>contigmalloc(), then it is simply the result of earlier, successful
> >>>>contigmalloc() calls, or for that matter any other physical memory
> >>>>allocation calls, having depleted the pool of free pages to the point
> >>>>that the page daemon runs and invokes vm_pageout_oom().
> >>>does it mean that those previous allocations relied on memory
> >>>overbooking ?
> >>Yes.
> >>
> >>>Is there a way to avoid that, then ?
> >>I believe that malloc()'s default minimum allocation size is 4MB.  You
> >>could reduce that.
> >>
> >>Alternatively, you can enable MALLOC_PRODUCTION.
> >i tried this, and as others mentioned it makes life
> >better and reduces the problem but contigmalloc still triggers
> >random process kills.
>
> I would be curious to see a stack backtrace when vm_pageout_oom() is called.

you mean a backtrace of the process(es) that get killed ?
I'll see if i manage to generate something, not easy because
this is a picobsd image and there is barely anything available.

I am trying to see if i can remove the memory overcommit,
but limited success so far.
I have built a kernel with "options NO_SWAPPING" but while it
makes vm.swap_enabled: 0 i still see vm.swap_reserved grow
beyond available RAM size. As an example, on a VM with 128MB
of RAM, of which about 28M used for a MFS root filesystem, i get
the following.

vm.vmtotal:
     System wide totals computed every five seconds: (values in kilobytes)
     ===============================================
     Processes:              (RUNQ: 1 Disk Wait: 1 Page Wait: 0 Sleep: 9)
     Virtual Memory:         (Total: 1074551344K Active: 738328K)
     Real Memory:            (Total: 17208K Active: 13368K)
     Shared Virtual Memory:  (Total: 7788K Active: 7788K)
     Shared Real Memory:     (Total: 5024K Active: 5024K)
     Free Memory:    68160K

# sysctl vm | grep swap
vm.swap_enabled: 0
vm.nswapdev: 0
vm.swap_async_max: 4
vm.swap_reserved: 149917696   <--- varies from ~140795904 to 160e6 and up
vm.swap_total: 0
vm.stats.vm.v_swappgsout: 0
vm.stats.vm.v_swappgsin: 0
vm.stats.vm.v_swapout: 0
vm.stats.vm.v_swapin: 0
vm.disable_swapspace_pageouts: 0
vm.defer_swapspace_pageouts: 0
vm.swap_idle_enabled: 0
vm.overcommit: 0

--------------

cheers
luigi



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120824165428.GA17495>