On Tue, 8 Jul 2003 10:22:25 -0700
Andreas Dilger <adilger@clusterfs.com> wrote:
> On Jul 08, 2003 13:46 +0200, Andi Kleen wrote:
> > On Tue, 08 Jul 2003 15:28:27 +0000 bzzz@tmi.comex.ru wrote:
> > > dynlocks implements 'lock namespace', so you can lock A for namepace N1 and
> > > lock B for namespace N1 and so on. we need this because we want to take lock
> > > on _part_ of directory.
> >
> > Ok, a mini database lock manager. Wouldn't it be better to use a small hash
> > table and lock escalation on overflow for this? Otherwise you could
> > have quite a lot of entries queued up in the list if the server is slow.
>
> That was my initial thought also, but the number of locks that are in
> existence at one time are very small (i.e. number of threads active in
> a directory at one time). Having a "more scalable" locking setup will,
> I think, hurt performance for the common case.
I don't see how it will be slower than the current patch.
The main advantage of lock escalation is that the worst case is bounded
very closely (worst it is just like currently with the single lock)
-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Jul 15 2003 - 22:00:28 EST