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)? And this shared mem approach will work with both threaded as well as multi-process servers? If so, this sounds like a good plan to me.
