serverid(s)_exist, critical path work.

[simo]

On Thu, 2013-02-07 at 15:54 +0100, Volker Lendecke wrote:
> On Thu, Feb 07, 2013 at 09:16:56AM -0500, Ira Cooper wrote:
> > epoll and friends are very scalable for what they are, but you are still
> > taking a system call hit when you use them.  And at least on Solaris
> > that'll kill you.
> 
> Ok, doing locking without syscalls, that's what futexes are
> for under Linux at least I guess. But they are not 100%
> robust, rogue memory writes could clobber the robust list.
> 
> At this moment I am more interested in graceful degradation.
> Linux fcntl completely falls over when someone takes the
> allrecord lock, thousands of waiters pile up an the
> allrecord lock is dropped. This makes the machine completely
> unusable for a while, sending the SMB clients into timeouts.
> I had thought that I can get away without the allrecord
> lock, but ctdb definitely depends on the ability to freeze
> all access to the database. This together with the non 100%
> robustness of robust mutexes makes them look less shiny than
> they initially did.

Well if you want to avoid the syscall you need to always consider that
rogue writes may destroy memory locations. It's either/or, so I guess
what you need to choose is whether you can accept the risk and do
everything in user space using shared memory or similar techniques or
whether the risk is too high and you need the kernel to act as arbiter.

I wonder if there is a way to set canaries from user space to prevent
processes to accidentally clobber memory areas with large memcpy or
similar ... maybe a clever setting of mmap regions ...

I've been using memory barrier and synchronization primitives to
implement single writer multiple readers w/o locking, and robust mutexes
basically do the same I think.

Maybe there is a way to combine robust mutexes for performance with a
fallback to fcntl locks for recovering from very bad situations ?

Simo.

-- 
Simo Sorce
Samba Team GPL Compliance Officer <simo at samba.org>
Principal Software Engineer at Red Hat, Inc. <simo at redhat.com>