[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: FSFS caching and ra_local

From: Stefan Fuhrmann <eqfox_at_web.de>
Date: Sat, 17 Sep 2011 10:10:40 +0200

On 16.09.2011 20:42, Philip Martin wrote:
> Philip Martin<philip.martin_at_wandisco.com> writes:
>
>> At startup the command line client disables the new FSFS caching in
>> subversion/svn/main.c:main (I recall that at one point FSFS cache
>> initialisation was expensive but I believe that is no longer the case):
It is correct that FSFS cache initialization is no longer
expensive for sub-GB cache sizes. I remember,
however, that you identified a problem with memory
consumption in concurrent test runs (16M default
instead of 1 or 2M per SVN process).
>> /* Per default, disable large expensive FS caching on the client side.
>> * We can still chose a different size for that cache later in the
>> * startup phase, e.g. after reading config files. If that does not
>> * happen until the first FSFS repository get opened, low initialization
>> * overhead caches will be used for the most time-critical structures.
>> *
>> * This is only relevant for FSFS over ra_local. */
>> settings = *svn_cache_config_get();
>> settings.cache_size = 0x0;
>> svn_cache_config_set(&settings);
>>
>> but I don't see where we ever set it to a non-zero value or how we allow
>> the user to control the cache size.
This statement refers to clients like TSVN that use longer-lived
RA sessions in a number of cases.
>> Have we forgotten to do that bit? At the very least I think we should
>> have a config setting.
> r1171708 enables FSFS caching in the command line client by default and
> introduces config:miscellaneous:memory-cache-size.
Looks good.
> I need to check
> whether programs such as svnadmin that have a -M option should also
> check the config option.
Makes sense as long as the command line takes precedence.

-- Stefan^2.
Received on 2011-09-17 10:11:19 CEST

This is an archived mail posted to the Subversion Dev mailing list.