On 08.03.2012 01:28, Stefan Sperling wrote:
> On Wed, Mar 07, 2012 at 11:40:40PM +0100, Stefan Fuhrmann wrote:
>> Hi all,
>>
>> The revprop caching I introduced in r1296604, -10
>> plus -7211 (kudos to Daniel) has an issue when it
>> comes to making long-lived fs_t detect revprop
>> changes. OTOH, I think that it also provides a huge
>> performance boost when you use clients like TSVN
>> that fire a large number of "svn ls -v"-esque queries.
>>
>> Since the FS API has no means to indicate that a
>> bunch of small-grained API calls actually belong to
>> some lager RA request, the revprop-gen file would
>> have to be checked on *every* revprop read. I.e.
>> the number of OS-level file operations is the same
>> as with reading the revprop file directly.
>> [Note to self: design FS2 such that all data access
>> is done in the context of query / transaction objects]
>>
>> So, I made up my mind on how to solve the problem
>> and this is what I intend to do:
>>
>> * undo the above-mentioned revs on /trunk
>> * open a branch and re-apply them
>> * introduce revprop caching as a third tuning option
>> next to "fulltext" and "deltas"
>> * introduce a new, private API that provides machine-
>> wide, named atomics (using the APR shared mem
>> API as a basis). Maybe, this will turn out to be useful
>> for other sync. issues in the future.
>> * use the that new svn__named_atomic API to
>> replace the revprop-gen file as well as the corresponding
>> member in fs_t, i.e. check the revprop gen before
>> *every* revprop read.
>>
>> With that we could at least provide revprop caching
>> for repos that are accessed from a single machine
>> using only 1.8+ servers to write revprops. One would
>> assume that this is the case for must 1.8 users.
>>
>> If all works out as intended, the changes will soon
>> be ready for /trunk.
> So, in layman's terms, you're saying that instead of storing revprop
> generation numbers in a file they are going to be stored in atomically
> accessed shared memory, to avoid file i/o overhead on every revprop read
> (i/o which would otherwise void the purpose of the cache)?
Exactly.
> And this shared mem approach will work with both threaded as well as
> multi-process servers?
Yes. And the plan is that the revprop cache will
be deactivated if the shared memory could not
be initialized / connected to.
> If so, this sounds like a good plan to me.
>
-- Stefan^2.
Received on 2012-03-08 01:42:37 CET