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.
Received on 2012-03-08 01:29:22 CET