You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Paul Burba <pt...@gmail.com> on 2009/05/05 16:17:09 UTC
Re: svn commit: r37137 - in trunk/subversion: libsvn_fs_base
tests/libsvn_fs_base
On Thu, Apr 9, 2009 at 12:27 PM, C. Michael Pilato <cm...@collab.net> wrote:
> ---------- Forwarded message ----------
> From: cmpilato@tigris.org
> To: svn@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
Re: svn commit: r37137 - in trunk/subversion: libsvn_fs_base
tests/libsvn_fs_base
Posted by Greg Stein <gs...@gmail.com>.
It never hurts for a fourth review, but yah... I'll +1 this sucker this evening.
Thx!
-g
On Tue, May 5, 2009 at 18:17, Paul Burba <pt...@gmail.com> wrote:
> On Thu, Apr 9, 2009 at 12:27 PM, C. Michael Pilato <cm...@collab.net> wrote:
>
>> ---------- Forwarded message ----------
>> From: cmpilato@tigris.org
>> To: svn@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=2070651