On Mon, May 5, 2014 at 11:50 AM, Bert Huijben <bert_at_qqmail.nl> wrote:
>
> > -----Original Message-----
> > From: Ivan Zhakov [mailto:ivan_at_visualsvn.com]
> > Sent: maandag 5 mei 2014 10:26
> > To: Stefan Fuhrmann
> > Cc: Subversion Development; Stefan Fuhrman
> > Subject: Re: svn commit: r1590405 - in /subversion/trunk: build.conf
> > subversion/include/private/svn_subr_private.h
> > subversion/libsvn_repos/log.c subversion/libsvn_subr/bit_array.c
> >
> > On 5 May 2014 03:13, Stefan Fuhrmann <stefan.fuhrmann_at_wandisco.com>
> > wrote:
> > >
> > >
> > >
> > > On Tue, Apr 29, 2014 at 4:29 PM, Ivan Zhakov <ivan_at_visualsvn.com>
> wrote:
> > >>
> > >> On 29 April 2014 17:54, Stefan Fuhrmann
> > <stefan.fuhrmann_at_wandisco.com>
> > >> wrote:
> > >> > On Mon, Apr 28, 2014 at 8:11 AM, Ivan Zhakov <ivan_at_visualsvn.com>
> > wrote:
> > >> >>
> > >> >> eOn 27 April 2014 19:27, <stefan2_at_apache.org> wrote:
> > >> >> > Author: stefan2
> > >> >> > Date: Sun Apr 27 15:27:46 2014
> > >> >> > New Revision: 1590405
> > >> >> >
> > >> >> > URL: http://svn.apache.org/r1590405
> > >> >> > Log:
> > >> >> > More 'svn log -g' memory usage reduction. We use a hash to keep
> > >> >> > track
> > >> >> > of all revisions reported so far, i.e. easily a million.
> > >> >> >
> > >
> > > > * Some system provided APR (1.5+ in particular) uses mmap
> > >
> > >> > to allocate memory. I.e. for every block, e.g. 8k, there is a
> > >> > separate mmap call. The Linux default is 65530 (sic!) mmap
> > >> > regions per process. Slowly allocating pools can trigger OOM
> > >> > errors after only 512MB actual memory usage (sum across
> > >> > all threads). I already prepared a patch for that.
> > >> >
> > >> Ouch, I didn't know that. I was thinking that MMAP APR pool allocator
> > >> is experimental and is not enabled by default.
> > >
> > >
> > > It is not enabled by default, I guess but the
> > > package responsible decided to enable it anyway.
> > >
> > Thanks for information.
>
> In that case I think we should try to fix APR to remove this limitation,
> instead of rewriting our own code to cope with this.
> When it uses mmap as allocator it should request bigger chunks from the OS.
>
> I don't think mmap() will be faster than the default allocator for such
> small chunks... I would expect quite the opposite, unless code is using big
> chunks.
>
I already have two patches for it. Just hadn't found the time
to submit them. (I just arrived in NYC for svnlive 2014).
-- Stefan^2.
Received on 2014-05-06 00:24:31 CEST