[PATCH] CTDB locking changes

[Martin Schwenke]

On Tue, 29 Jul 2014 15:40:06 +1000, Amitay Isaacs <amitay at gmail.com>
wrote:

> > Single queue for pending requests is not good enough.  On a loaded system
> > there can thousands of lock requests in the pending queue.  In that case,
> > per database queues definitely improves the cpu utilization for
> > scheduling.  Here are all the locking changes with additional patch for per
> > database queues.
> >
> > I would appreciate review and comments/suggestions.
> >
> > Amitay.
> >
> >
> I have split the last patch to make the changes smaller and easier to
> understand.
> 
> The latest changes are available in my tree.
> 
> 
> http://git.samba.org/?p=amitay/samba.git;a=shortlog;h=refs/heads/ctdb-locking

Latest version includes (very) minor suggestions from my review.

Reviewed-by: Martin Schwenke <martin at meltin.net>

The only issue I can still see is a theoretical possibility of unfair
scheduling.  The databases are always searched in (the same) order to
find a record lock to schedule.  If a database in the list has lots of
pending locks queued and more coming in (and landing in the pending
queue) then, if active locks are processed at least as fast as they
come in, that database will be the only one with locks scheduled.

However, that's incredibly unlikely.  Amitay pointed that taking a lock
is much more expensive than queuing a pending lock request, and that
expense is exaggerated because requests only get added to the pending
queue when there's already contention.

If the very unlikely event that this can actually happen, the
scheduling code can keep a static pointer to the next database to
process, advance this pointer before returning with a request to
schedule, and the database list can be treated as circular...  but
let's worry about that if we see a problem... ;-)

peace & happiness,
martin