From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com [IPv6:2a00:1450:4864:20::135]) by sourceware.org (Postfix) with ESMTPS id B25B43857C67 for ; Sat, 5 Jun 2021 08:56:17 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org B25B43857C67 Received: by mail-lf1-x135.google.com with SMTP id f30so17710178lfj.1 for ; Sat, 05 Jun 2021 01:56:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=ILIrHKLM5BATuWgmLULRPhKcib+qBSgE3U9c4pZR14s=; b=rmVb9OqGKEsf+SdQQ5tZPsDLk7leL8tqaUGpVSVzhiV4NlVYUkMd9bvP1K5oYFYHJY C+E262JLhwPq1VH8uoPY1BnIby3w4KS+WfCnL7/XR907EDdwqNgIrXbcnbBkWzKa4v1p XPbnXdYgloyeCUJj+sxphapszhHTHB0PlKxoa4VJzUBXqmL6S6DfupndB8Mpqju41aUJ L79SsIENTSrqEIHiDghwhSpSi2xnsgnrbqQVa37Rr6REk37hbPO99uUB/PDzdMICjVtL Ya7miOWC860I7FrW7n6NLsJccO2xQRDFcW31KADSSP44h/lqRtTE2xEPvEWuV2QfzDrI eHZQ== X-Gm-Message-State: AOAM533FFtfGCETA4o0kywIAIqJkydmd+Ug3GoV+XROgH0Le0zuGJkBY ibbRw+bvyoNtDjuEIq9BjBU= X-Google-Smtp-Source: ABdhPJwJD/KAhhiahlwsu+Y5RAnyMZPeqS9CtG0MMkcIB/o8rGlXMpg3PJ28VLkZscUzvQbPsxVDXQ== X-Received: by 2002:ac2:52b3:: with SMTP id r19mr5598865lfm.525.1622883375992; Sat, 05 Jun 2021 01:56:15 -0700 (PDT) Received: from [192.168.1.2] (broadband-5-228-51-184.ip.moscow.rt.ru. [5.228.51.184]) by smtp.gmail.com with ESMTPSA id a20sm978035ljk.29.2021.06.05.01.56.14 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 05 Jun 2021 01:56:14 -0700 (PDT) Subject: Re: [PATCH v4 00/15] Add futex2 syscalls To: Nicholas Piggin , =?UTF-8?Q?Andr=c3=a9_Almeida?= Cc: acme@kernel.org, Sebastian Andrzej Siewior , corbet@lwn.net, Davidlohr Bueso , Darren Hart , fweimer@redhat.com, joel@joelfernandes.org, kernel@collabora.com, krisman@collabora.com, libc-alpha@sourceware.org, linux-api@vger.kernel.org, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, malteskarupke@fastmail.fm, Ingo Molnar , Peter Zijlstra , pgriffais@valvesoftware.com, Peter Oskolkov , Steven Rostedt , shuah@kernel.org, Thomas Gleixner , z.figura12@gmail.com References: <20210603195924.361327-1-andrealmeid@collabora.com> <1622799088.hsuspipe84.astroid@bobo.none> <1622853816.mokf23xgnt.astroid@bobo.none> From: Andrey Semashev Message-ID: <6d8e3bb4-0cef-b991-9a16-1f03d10f131d@gmail.com> Date: Sat, 5 Jun 2021 11:56:13 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 MIME-Version: 1.0 In-Reply-To: <1622853816.mokf23xgnt.astroid@bobo.none> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=1.3 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, NICE_REPLY_A, RCVD_IN_BARRACUDACENTRAL, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.2 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jun 2021 08:56:19 -0000 On 6/5/21 4:09 AM, Nicholas Piggin wrote: > Excerpts from André Almeida's message of June 5, 2021 6:01 am: >> Às 08:36 de 04/06/21, Nicholas Piggin escreveu: > >>> I'll be burned at the stake for suggesting it but it would be great if >>> we could use file descriptors. At least for the shared futex, maybe >>> private could use a per-process futex allocator. It solves all of the >>> above, although I'm sure has many of its own problem. It may not play >>> so nicely with the pthread mutex API because of the whole static >>> initialiser problem, but the first futex proposal did use fds. But it's >>> an example of an alternate API. >>> >> >> FDs and futex doesn't play well, because for futex_wait() you need to >> tell the kernel the expected value in the futex address to avoid >> sleeping in a free lock. FD operations (poll, select) don't have this >> `value` argument, so they could sleep forever, but I'm not sure if you >> had taken this in consideration. > > I had. The futex wait API would take a fd additional. The only > difference is the waitqueue that is used when a sleep or wake is > required is derived from the fd, not from an address. > > I think the bigger sticking points would be if it's too heavyweight an > object to use (which could be somewhat mitigated with a simpler ida > allocator although that's difficult to do with shared), and whether libc > could sanely use them due to the static initialiser problem of pthread > mutexes. The static initialization feature is not the only benefit of the current futex design, and probably not the most important one. You can work around the static initialization in userspace, e.g. by initializing fd to an invalid value and creating a valid fd upon the first use. Although that would still incur a performance penalty and add a new source of failure. What is more important is that waiting on fd always requires a kernel call. This will be terrible for performance of uncontended locks, which is the majority of time. Another important point is that a futex that is not being waited on consumes zero kernel resources while fd is a limited resource even when not used. You can have millions futexes in userspace and you are guaranteed not to exhaust any limit as long as you have memory. That is an important feature, and the current userspace is relying on it by assuming that creating mutexes and condition variables is cheap. Having futex fd would be useful in some cases to be able to integrate futexes with IO. I did have use cases where I would have liked to have FUTEX_FD in the past. These cases arise when you already have a thread that operates on fds and you want to avoid having a separate thread that blocks on futexes in a similar fashion. But, IMO, that should be an optional opt-in feature. By far, not every futex needs to have an fd. For just waiting on multiple futexes, the native support that futex2 provides is superior. PS: I'm not asking FUTEX_FD to be implemented as part of futex2 API. futex2 would be great even without it.