lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <3659bc06-f8f3-31ff-b4d6-99aee4ed2199@collabora.com>
Date:   Thu, 4 Mar 2021 16:15:21 -0300
From:   André Almeida <andrealmeid@...labora.com>
To:     Theodore Ts'o <tytso@....edu>
Cc:     Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Darren Hart <dvhart@...radead.org>,
        linux-kernel@...r.kernel.org, Steven Rostedt <rostedt@...dmis.org>,
        Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
        kernel@...labora.com, krisman@...labora.com,
        pgriffais@...vesoftware.com, z.figura12@...il.com,
        joel@...lfernandes.org, malteskarupke@...tmail.fm,
        linux-api@...r.kernel.org, fweimer@...hat.com,
        libc-alpha@...rceware.org, linux-kselftest@...r.kernel.org,
        shuah@...nel.org, acme@...nel.org, corbet@....net
Subject: Re: [RFC PATCH v2 00/13] Add futex2 syscall

Hi Ted,

Às 12:01 de 04/03/21, Theodore Ts'o escreveu:
> 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.  

futex2 has the same design in that aspect, no syscall is needed in the 
happy path. Did something in the cover letter gave the impression that 
is not the case? I would like to reword it to clarify this.

> 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
> 

Thanks,
	André

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ