From owner-freebsd-arch@freebsd.org Fri Apr 9 09:56:33 2021 Return-Path: Delivered-To: freebsd-arch@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 960525D2163 for ; Fri, 9 Apr 2021 09:56:33 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 4FGtnY2xFBz4X12 for ; Fri, 9 Apr 2021 09:56:33 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: by mailman.nyi.freebsd.org (Postfix) id 6212B5D22F5; Fri, 9 Apr 2021 09:56:33 +0000 (UTC) Delivered-To: arch@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 608D55D1EFE for ; Fri, 9 Apr 2021 09:56:33 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from relay4-d.mail.gandi.net (relay4-d.mail.gandi.net [217.70.183.196]) (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 4FGtnX5WmZz4X10 for ; Fri, 9 Apr 2021 09:56:29 +0000 (UTC) (envelope-from avg@FreeBSD.org) X-Originating-IP: 195.64.148.76 Received: from [192.168.0.88] (unknown [195.64.148.76]) (Authenticated sender: andriy.gapon@uabsd.com) by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id 55268E000A for ; Fri, 9 Apr 2021 09:56:27 +0000 (UTC) From: Andriy Gapon Subject: adaptive spinning: fall back to sleep / block? To: arch@FreeBSD.org References: <202102251856.11PIuxwF020948@gitrepo.freebsd.org> <19884f0f-115d-a60c-2ef2-72400f96f8a7@uabsd.com> Message-ID: Date: Fri, 9 Apr 2021 12:56:26 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:78.0) Gecko/20100101 Firefox/78.0 Thunderbird/78.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4FGtnX5WmZz4X10 X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [0.00 / 15.00]; ASN(0.00)[asn:29169, ipnet:217.70.176.0/20, country:FR]; local_wl_from(0.00)[FreeBSD.org] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Apr 2021 09:56:33 -0000 Until I recently looked at the actual code I was under an impression that the adaptive spinning is bounded and that after some time / number of spins a thread would go to a sleep queue or a turnstile. But it looks that the spinning is actually unbounded as long as its conditions hold (some other thread owns the lock and that thread is running, the owner could be changing too). In my opinion, it does not make sense to spin for "too long". If there was not an opportunity to take a lock quickly, then it's better to block waiting for it rather than keep occupying a processor. For instance, the spinning can prevent another runnable thread from running. I think that if a lock is heavily contended or its hold times are on the longer side (or both), then the adaptive spinning can make the system behavior (performance, responsiveness) worse. Finally, I was under an impression that 'adaptive' meant some heuristic on whether and when to do the spinning. _A lock owner is running_ seems to be too simple to qualify as 'adaptive'. As an example, this looks like a relatively sophisticated implementation of the "adaptiveness": http://hg.openjdk.java.net/jdk8/jdk8/hotspot/file/87ee5ee27509/src/share/vm/runtime/objectMonitor.cpp#l1919 But, JIMHO, simply having a hard limit on the spin count would be better than what we have now. P.S. This is not an area that I know well, so my confusion and ideas may be absurd. On the other hand, I could not find any justification for the current unbounded "adaptive" spinning. -- Andriy Gapon