Date: Fri, 1 Sep 2017 22:24:33 +0300 From: Konstantin Belousov <kostikbel@gmail.com> To: Paul <devgs@ukr.net> Cc: freebsd-stable@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: High CPU usage in kernel on highly contended lock file Message-ID: <20170901192433.GA1700@kib.kiev.ua> In-Reply-To: <1504278581.38180443.tad3fj7o@frv33.fwdcdn.com> References: <1504278581.38180443.tad3fj7o@frv33.fwdcdn.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Sep 01, 2017 at 06:21:00PM +0300, Paul wrote: > > It seems that a lot of CPU resources are spend when trying to get exclusive lock on file from multiple processes concurrently. By multiple i mean hundreds. > It seems that there's an initial cost of fcntl() call. Each process that tries to lock the file consumes some amount of CPU and cools down. > However, each repeated fcntl() call will consume same amount of resources again. It seems as if entering the "wait queue" is expensive. Yes, our lockf is somewhat expensive, I believe it is because the implementation tries to maintain the fairness. In other words, the lock requesters are put on queue in order. Another heavy feature is the deadlock detection. POSIX seems to state that the detection is optional, but perhaps it is required for reliable operations of the network locking protocols for NFS. Sure, there can be opportunities to optimize the current algorithms. Somebody interested in such optimization should start with profiling the kernel.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20170901192433.GA1700>