On Thu, Apr 9, 2009 at 12:27 PM, C. Michael Pilato <cmpilato_at_collab.net> wrote:
> ---------- Forwarded message ----------
> From: cmpilato_at_tigris.org
> To: svn_at_subversion.tigris.org
> Date: Thu, 9 Apr 2009 09:24:28 -0700
> Subject: svn commit: r37137 - in trunk/subversion: libsvn_fs_base tests/libsvn_fs_base
> Author: cmpilato
> Date: Thu Apr 9 09:24:28 2009
> New Revision: 37137
>
> Log:
> Attempt to button down the BDB backend's memory usage by allowing trail
> producers to tell that subsystem to discard all memory associated with
> the trail.
>
> Most of the time, this pool usage waste isn't a problem (because of
> better pool practices in higher layers). But mod_dav and mod_dav_svn
> have notoriously wicked pool usage behavior, and I'm tired of having
> the theoretically niceties of our pool usage guidelines getting in the
> way of Subversion working. Why should a simple 'svn ls -v' of a
> directory with 10,000 files exhaust all the memory on my 2Gb laptop?
> It shouldn't, ahd if this kind of change is what I have to do to get
> that leakage back down to "only" 339Mb, I feel compelled to do it.
>
> An arguably cleaner approach would have been to add a 'result_pool'
> argument to the txn_body_* function type which is the same pool passed
> to svn_fs_base__retry_txn(). That would allow the txn_body_*
> functions (which already operate with 'trail' and 'trail->pool' today)
> to use the 'result_pool' argument as a final destination for
> returnable stuff and 'trail->pool' for scratch work. (And then
> do_retry() function would, of course, always whack trail->pool when it
> was finished with a trail.) I've filed issue #3395 to track this
> possible future enhancement.
>
> Reviewed by: gstein
Hi Greg,
Mike nominated this for backport to 1.6.2, it has two votes already.
I've taken a brief look at it last night, but before I dive in for a
deeper review I thought it worth checking to see if you, having
already reviewed the patch, were good for a +1 backport vote.
Paul
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2070638
Received on 2009-05-05 18:18:13 CEST