You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Greg Stein <gs...@lyra.org> on 2003/11/12 00:31:19 UTC
comments, please: rev 7706 - trunk/subversion/libsvn_repos
My concern around this is if the deltification process holds locks for a
"long time", then its lower priority could cause the locks to be held
longer than necessary, which then delays the processes we actually want to
operate "fast". Of course, the OS should "bump" the priority of the
deltify if everybody is waiting for its locks.
Any ways... it seems like it should be fine, but wanted to ask the list
whether anybody can see a problem here.
Cheers,
-g
On Tue, Nov 11, 2003 at 05:45:35PM -0600, gstein@tigris.org wrote:
>....
> Log:
> Slight tweaks to the recommendation of the deltify process.
>
> * libsvn_repos/repos.c:
> (create_hooks): for the 'svnadmin deltify', put it into the background,
> and drop its priority a little bit. we don't want it to compete with
> the primary operation of the server.
>
>
> Modified: trunk/subversion/libsvn_repos/repos.c
> ==============================================================================
> --- trunk/subversion/libsvn_repos/repos.c (original)
> +++ trunk/subversion/libsvn_repos/repos.c Tue Nov 11 17:45:34 2003
> @@ -639,7 +639,7 @@
> APR_EOL_STR
> "# Deltify predecessors of things changed in this revision."
> APR_EOL_STR
> - "svnadmin deltify \"$REPOS\" -r \"$REV\""
> + "nice -2 svnadmin deltify \"$REPOS\" -r \"$REV\" &"
> APR_EOL_STR
> APR_EOL_STR
> "commit-email.pl \"$REPOS\" \"$REV\" commit-watchers@example.org"
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: comments, please: rev 7706 - trunk/subversion/libsvn_repos
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Tuesday, November 11, 2003 16:31:19 -0800 Greg Stein <gs...@lyra.org>
wrote:
> My concern around this is if the deltification process holds locks for a
> "long time", then its lower priority could cause the locks to be held
> longer than necessary, which then delays the processes we actually want to
> operate "fast". Of course, the OS should "bump" the priority of the
> deltify if everybody is waiting for its locks.
>
> Any ways... it seems like it should be fine, but wanted to ask the list
> whether anybody can see a problem here.
On Unix, if it's pthread locks, some OSes (i.e. Solaris) will detect the
priority inversion and deal with it by bumping the lower priority process
to the priority of the process that is waiting on the locks (as you
described). But, I'm not really sure if that applies to file-based locks
or even BDB locks for that matter. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org