Fw: Re: Implemented OPLOCK for FreeBsd

[Mike Smith]

> On Fri, Sep 07, 2001 at 05:49:15PM -0700, Mike Smith wrote:
> 
> > If it's a system-wide tunable rather than a per-application or
> > per-delivery-point tunable, this isn't entirely ideal.
> 
> No, it's a per-application tunable. In Linux there is I
> believe a system wide limit of 1024 on top of that. If
> this limit is a problem we can increase it or make it a
> system wide tunable.

This is a fairly Linux-centric view of the situation, for something
you're arguing should be a standard.  It's also not very
robust-sounding.  (ie. it requires manual intervention and possible
kernel changes just to deal with possible performance issues.)

> How does this differ from the resource requirements for kqueues ?
> Other than the context switches, I would imagine they have the
> same resource consumption problem.

knotes (the kqueue event objects) are allocated on demand, and there
are no hard limits on them (so that unless you blow out kernel memory,
you don't have the starvation issues).  As Jonathan also pointed out,
the sender is synchronously notified of a failure to queue a knote
as well - I don't know whether Posix.4 signals provide this (I would
hope so)/

> Remember, breaking an oplock should be a rare thing. Samba self
> tunes to not grant oplocks if a break happens more than once
> when a file open is being processed.

This is a salient point; part of what I've been asking about. I the
sort of lock traffic we're talking about here is low, most of the
performance issues are moot.  Please bear in mind that just because
you know a lot about SMB it doesn't necessarily follow that we all
do. 8)

Regards,
Mike