Re: [PATCH 0/7] dlm: overview

From: David Teigland
Date: Tue Apr 26 2005 - 22:30:43 EST

On Tue, Apr 26, 2005 at 11:48:45AM -0700, Mark Fasheh wrote:
> On Tue, Apr 26, 2005 at 01:39:30PM +0800, David Teigland wrote:

> > No. What kind of performance measurements do you have in mind? Most
> > dlm lock requests involve sending a message to a remote machine and
> > waiting for a reply. I expect this network round-trip is the bulk of
> > the time for a request, which is why I'm a bit confused by your
> > question.

> Resource lookup times, times to deliver events to clients (asts, basts,
> etc) for starters. How long does recovery take after a node crash? How
> does all of this scale as you increase the number of nodes in your
> cluster? Sure, network speed is a part of the equation, but it's not
> the *whole* equation and I've seen dlms that can get downright nasty
> when it comes to recovery speeds, etc.

Ok, we'll look into how to measure some of that in a way that's

> > > My main concern is that I have not seen anything relying on this
> > > code do "reasonably well". eg can you show gfs numbers w/ number of
> > > nodes and scalability ?
> >
> > I'd suggest that if some cluster application is using the dlm and has
> > poor performance or scalability, the reason and solution lies mostly
> > in the app, not in the dlm. That's assuming we're not doing anything
> > blatantly dumb in the dlm, butI think you may be placing too much
> > emphasis on the role of the dlm here.

> Well, obviously the dlm is only one component of an entire system, but
> for a cluster application it can certainly be an important component,
> one whose performance is worth looking into. I don't think asking for
> this information is out of the question.

GFS measurements will wait until gfs comes along, but we can do some dlm
measuring now.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at