From owner-freebsd-hackers@freebsd.org  Fri Sep  1 19:24:43 2017
Return-Path: <owner-freebsd-hackers@freebsd.org>
Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
 [IPv6:2001:1900:2254:206a::19:1])
 by mailman.ysv.freebsd.org (Postfix) with ESMTP id 726F1E01B2D;
 Fri,  1 Sep 2017 19:24:43 +0000 (UTC)
 (envelope-from kostikbel@gmail.com)
Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
 (Client did not present a certificate)
 by mx1.freebsd.org (Postfix) with ESMTPS id E6475F05;
 Fri,  1 Sep 2017 19:24:42 +0000 (UTC)
 (envelope-from kostikbel@gmail.com)
Received: from tom.home (kib@localhost [127.0.0.1])
 by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id v81JOYrB099198
 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO);
 Fri, 1 Sep 2017 22:24:34 +0300 (EEST)
 (envelope-from kostikbel@gmail.com)
DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua v81JOYrB099198
Received: (from kostik@localhost)
 by tom.home (8.15.2/8.15.2/Submit) id v81JOXvF099197;
 Fri, 1 Sep 2017 22:24:33 +0300 (EEST)
 (envelope-from kostikbel@gmail.com)
X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com
 using -f
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>
References: <1504278581.38180443.tad3fj7o@frv33.fwdcdn.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1504278581.38180443.tad3fj7o@frv33.fwdcdn.com>
User-Agent: Mutt/1.8.3 (2017-05-23)
X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00,
 DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no
 autolearn_force=no version=3.4.1
X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home
X-BeenThere: freebsd-hackers@freebsd.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Technical Discussions relating to FreeBSD
 <freebsd-hackers.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-hackers>, 
 <mailto:freebsd-hackers-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-hackers/>
List-Post: <mailto:freebsd-hackers@freebsd.org>
List-Help: <mailto:freebsd-hackers-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-hackers>, 
 <mailto:freebsd-hackers-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 01 Sep 2017 19:24:43 -0000

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.