Fw: Re: Implemented OPLOCK for FreeBsd
jra at samba.org
Fri Sep 7 19:58:05 GMT 2001
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.
More information about the samba-technical