Fw: Re: Implemented OPLOCK for FreeBsd

[Jeremy Allison]

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.

> Off the top of my head, I'm worried about:
> 
>  - Resource consumption for the signal queues, either in the case
>    of large numbers of pending notifications, or in a worse case
>    simply resource consumption in order to support such a large
>    number of pending notifications.  In a system where there is
>    no hard limit on the number of open files, a system-wide tunable
>    for the number of pending signals is no good anyway; you can
>    always blow the limit.
> 
>  - The efficiency of the signal delivery mechanism (four context
>    switches to deliver a single notification, and not necessarily well
>    synchronised with the application's internal activity).  In
>    addition, the way that Samba handles this (writing a flag into a
>    pipe) adds four more context switches.
> 
>  - The use of SIGINFO rather than a private signal number. (an
>    implementation quibble, I think)
> 
>  - The difficulty of handling signals well in a threaded 
>    application. (probably not an issue for Samba).

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.

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.

Jeremy.