On Mon, May 5, 2014 at 11:50 AM, Bert Huijben <b...@qqmail.nl> wrote:
> > > -----Original Message----- > > From: Ivan Zhakov [mailto:i...@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.fuhrm...@wandisco.com> > > wrote: > > > > > > > > > > > > On Tue, Apr 29, 2014 at 4:29 PM, Ivan Zhakov <i...@visualsvn.com> > wrote: > > >> > > >> On 29 April 2014 17:54, Stefan Fuhrmann > > <stefan.fuhrm...@wandisco.com> > > >> wrote: > > >> > On Mon, Apr 28, 2014 at 8:11 AM, Ivan Zhakov <i...@visualsvn.com> > > wrote: > > >> >> > > >> >> eOn 27 April 2014 19:27, <stef...@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.
