From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 18F88C43381 for ; Thu, 4 Mar 2021 15:03:49 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id E347F64F68 for ; Thu, 4 Mar 2021 15:03:48 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233073AbhCDPDT (ORCPT ); Thu, 4 Mar 2021 10:03:19 -0500 Received: from outgoing-auth-1.mit.edu ([18.9.28.11]:51200 "EHLO outgoing.mit.edu" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S232988AbhCDPDF (ORCPT ); Thu, 4 Mar 2021 10:03:05 -0500 Received: from cwcc.thunk.org (pool-72-74-133-215.bstnma.fios.verizon.net [72.74.133.215]) (authenticated bits=0) (User authenticated as tytso@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 124F1E6c002357 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 4 Mar 2021 10:01:15 -0500 Received: by cwcc.thunk.org (Postfix, from userid 15806) id A243015C3A88; Thu, 4 Mar 2021 10:01:14 -0500 (EST) Date: Thu, 4 Mar 2021 10:01:14 -0500 From: "Theodore Ts'o" To: =?iso-8859-1?Q?Andr=E9?= Almeida Cc: Thomas Gleixner , Ingo Molnar , Peter Zijlstra , Darren Hart , linux-kernel@vger.kernel.org, Steven Rostedt , Sebastian Andrzej Siewior , kernel@collabora.com, krisman@collabora.com, pgriffais@valvesoftware.com, z.figura12@gmail.com, joel@joelfernandes.org, malteskarupke@fastmail.fm, linux-api@vger.kernel.org, fweimer@redhat.com, libc-alpha@sourceware.org, linux-kselftest@vger.kernel.org, shuah@kernel.org, acme@kernel.org, corbet@lwn.net Subject: Re: [RFC PATCH v2 00/13] Add futex2 syscall Message-ID: References: <20210304004219.134051-1-andrealmeid@collabora.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20210304004219.134051-1-andrealmeid@collabora.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Mar 03, 2021 at 09:42:06PM -0300, André Almeida wrote: > ** Performance > > - For comparing futex() and futex2() performance, I used the artificial > benchmarks implemented at perf (wake, wake-parallel, hash and > requeue). The setup was 200 runs for each test and using 8, 80, 800, > 8000 for the number of threads, Note that for this test, I'm not using > patch 14 ("kernel: Enable waitpid() for futex2") , for reasons explained > at "The patchset" section. How heavily contended where the benchmarks? One of the benefits of the original futex was that no system call was necessary in the happy path when the lock is uncontended. Especially on a non-NUMA system (which are the far more common case), since that's where relying on a single memory access was a huge win for the original futex. I would expect that futex2 will fare worse in this particular case, since it requires a system call entry for all operations --- the question is how large is the delta in this worst case (for futex2) and best case (for futex) scenario. Cheers, - Ted