From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by sourceware.org (Postfix) with ESMTPS id 88F733858C52 for ; Thu, 28 Sep 2023 14:43:30 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 88F733858C52 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=goodmis.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=kernel.org Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id EC90A61414; Thu, 28 Sep 2023 14:43:29 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id B98C8C433C8; Thu, 28 Sep 2023 14:43:24 +0000 (UTC) Date: Thu, 28 Sep 2023 10:43:21 -0400 From: Steven Rostedt To: Peter Zijlstra Cc: Mathieu Desnoyers , linux-kernel@vger.kernel.org, Thomas Gleixner , "Paul E . McKenney" , Boqun Feng , "H . Peter Anvin" , Paul Turner , linux-api@vger.kernel.org, Christian Brauner , Florian Weimer , David.Laight@aculab.com, carlos@redhat.com, Peter Oskolkov , Alexander Mikhalitsyn , Chris Kennelly , Ingo Molnar , Darren Hart , Davidlohr Bueso , =?UTF-8?B?QW5kcsOp?= Almeida , libc-alpha@sourceware.org, Jonathan Corbet , Noah Goldstein , Daniel Colascione , longman@redhat.com, Florian Weimer Subject: Re: [RFC PATCH v2 1/4] rseq: Add sched_state field to struct rseq Message-ID: <20230928104321.490782a7@rorschach.local.home> In-Reply-To: <20230928103926.GI9829@noisy.programming.kicks-ass.net> References: <20230529191416.53955-1-mathieu.desnoyers@efficios.com> <20230529191416.53955-2-mathieu.desnoyers@efficios.com> <20230928103926.GI9829@noisy.programming.kicks-ass.net> X-Mailer: Claws Mail 3.17.8 (GTK+ 2.24.33; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,HEADER_FROM_DIFFERENT_DOMAINS,KAM_DMARC_STATUS,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Thu, 28 Sep 2023 12:39:26 +0200 Peter Zijlstra wrote: > As always, are syscalls really *that* expensive? Why can't we busy wait > in the kernel instead? Yes syscalls are that expensive. Several years ago I had a good talk with Robert Haas (one of the PostgreSQL maintainers) at Linux Plumbers, and I asked him if they used futexes. His answer was "no". He told me how they did several benchmarks and it was a huge performance hit (and this was before Spectre/Meltdown made things much worse). He explained to me that most locks are taken just to flip a few bits. Going into the kernel and coming back was orders of magnitude longer than the critical sections. By going into the kernel, it caused a ripple effect and lead to even more contention. There answer was to implement their locking completely in user space without any help from the kernel. This is when I thought that having an adaptive spinner that could get hints from the kernel via memory mapping would be extremely useful. The obvious problem with their implementation is that if the owner is sleeping, there's no point in spinning. Worse, the owner may even be waiting for the spinner to get off the CPU before it can run again. But according to Robert, the gain in the general performance greatly outweighed the few times this happened in practice. But still, if userspace could figure out if the owner is running on another CPU or not, to act just like the adaptive mutexes in the kernel, that would prevent the problem of a spinner keeping the owner from running. -- Steve