[Linux-cluster] GFS: more simple performance numbers

[David Teigland]

On Fri, Oct 29, 2004 at 02:40:33PM -0700, Daniel McNeil wrote:

> Can you explain what gfs does with the callback?  Does it drop the locks
> for all gfs inodes or just the ones that are not actively being used?
> Does gfs still cache the inode without holding the dlm lock?

It releases all its unused (cached) locks which includes releasing the
corresponding cached data.


> How much memory does a dlm lock take?  10,000 seems very small
> for machines today.
> 
> Would it make sense to limit the number of gfs inodes which,
> in turn, would limit the number of dlm_locks? 
> 
> It seems to me the number of inodes and number of dlm locks
> should scale together.

GFS is already quite good at limiting the caching it does without this
drop-locks mechanism.  The drop-locks callback is really an emergency
button that shouldn't be used regularly as it disrupts all the intelligent
things gfs is doing.

Since lock_dlm really has no idea when the dlm is setting up for a
potential recovery mem shortage, it can be argued that by default we
should ignore the callback -- that's what we did until recently.  So, this
callback, designed many years ago for very different (centralized) lock
managers, doesn't work too well for the dlm.  As I mentioned, there are
other better ways we can solve dlm recovery limitations.  Until then,
we'll hope to find some sensible defaults and guidelines on when/how to
configure /proc/cluster/lock_dlm/drop_count.

-- 
Dave Teigland  <teigland at redhat.com>