Fw: Re: Implemented OPLOCK for FreeBsd

[Mike Smith]

> Ok - I've done some checking on the 'net. SIGQUEUE_MAX is
> a system tunable. This means we're fine, and it is a scalable
> quantity for reliable signal delivery, as admins can always set
> it on a particular system.

If it's a system-wide tunable rather than a per-application or
per-delivery-point tunable, this isn't entirely ideal.

> Does this answer your scalability questinos w.r.t the existing
> interface ?

Not particularly; there are a bunch of potential concerns.  It's hard
to know which of them are applicable without some idea of how the
mechanism is actually used (hence asking you for some data based on
your existing implementations).

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).

As far as scalability, I'm less worried about "a lot of files open"
as I am about "surviving and performing well in the case where there
is a lot of oplock activity".

One of the missing pieces in this puzzle is defining what "a lot of
oplock activity" is.  If we're talking ten operations a second on
a heavily-loaded server, then all is well.  But if we're talking 
about thousands per second, then some of the above issues become
quite significant, and might bear further investigation.

Regards,
Mike