Fw: Re: Implemented OPLOCK for FreeBsd
msmith at freebsd.org
Fri Sep 7 20:02:50 GMT 2001
> 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.
More information about the samba-technical