From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf1-x12c.google.com (mail-lf1-x12c.google.com [IPv6:2a00:1450:4864:20::12c]) by sourceware.org (Postfix) with ESMTPS id 79BBC386FC1F for ; Tue, 8 Jun 2021 13:41:10 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 79BBC386FC1F Received: by mail-lf1-x12c.google.com with SMTP id n12so25137694lft.10 for ; Tue, 08 Jun 2021 06:41:10 -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=8CP8awcg95oWuVc3U+udiIOQfXQwkD1ELykPoeSDRf0=; b=pZ/2Y5y0CJF9e6/cJV8M00fvTQ+R68YwnH+ZQ5fwXR2sC/lrPFW37tDJNc15NvsOy9 XJzDzJdkzdKzRGAO40Yu2QEiamphVWpJJP8k2LcMZC6RXZD+NhqMVuwRHfpaJ4uOzjka ARPpSAT5ruiOINKK/T9m17PprV+RJ7Xm3E8g8+eo8M29ff67XRF8VFv3eGOMWVtIgAzP iSQipwR/smrIlFpqaNw0VD646aCmPbBk292EvHy/kVgRrlgKL/y+wMHIXioqMmlNwAvY bAgOc0ihQzwW4o3zPsJ6GBin6J9Uae58lmStq9xSm96hMWJ5rXqPX6ns7fSCprSFSRzW 8/Xg== X-Gm-Message-State: AOAM532pYeK6/+N3jhX98FdayepkWAnDWcWAIqwOO3Zc0K0zQHD7QjwR JwQ1hq+uozF+e5+2Tn3BsiM= X-Google-Smtp-Source: ABdhPJxyRgGCXscqZPEqdY3tizyXXZkHxIfRc0pL2h7PfHdsBirtbLZ3f0h4iLxhxFKq/sAN9wN8SQ== X-Received: by 2002:ac2:5084:: with SMTP id f4mr15801044lfm.466.1623159669392; Tue, 08 Jun 2021 06:41:09 -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 h4sm494809ljk.4.2021.06.08.06.41.07 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 08 Jun 2021 06:41:08 -0700 (PDT) Subject: Re: [PATCH v4 00/15] Add futex2 syscalls To: Greg KH Cc: Nicholas Piggin , =?UTF-8?Q?Andr=c3=a9_Almeida?= , 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: <1622853816.mokf23xgnt.astroid@bobo.none> <6d8e3bb4-0cef-b991-9a16-1f03d10f131d@gmail.com> <1622980258.cfsuodze38.astroid@bobo.none> <1623114630.pc8fq7r5y9.astroid@bobo.none> <8fa8b7fd-58ae-9467-138d-4ff4f32f68f7@gmail.com> <3fca0afa-d9db-a176-aad1-ff7db21ba4a2@gmail.com> From: Andrey Semashev Message-ID: Date: Tue, 8 Jun 2021 16:41:07 +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: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=0.6 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-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: Tue, 08 Jun 2021 13:41:11 -0000 On 6/8/21 4:27 PM, Greg KH wrote: > On Tue, Jun 08, 2021 at 04:18:42PM +0300, Andrey Semashev wrote: >> On 6/8/21 3:35 PM, Greg KH wrote: >>> On Tue, Jun 08, 2021 at 03:06:48PM +0300, Andrey Semashev wrote: >>>> On 6/8/21 2:13 PM, Greg KH wrote: >>> >>>>> So what's keeping the futex2 code from doing all that futex1 does so >>>>> that the futex1 code can be deleted internally? >>>> >>>> I think, André will answer this, but my guess is, as stated above, this is a >>>> lot of work and time while the intermediate version is already useful. >>> >>> useful to who? I still do not understand what users will be needing >>> this. All I can tell is a single userspace program wants to use it, and >>> that is a fork from the real project it was based on and that the >>> maintainers have no plan to merge it back. >>> >>> So who does need/want this? >> >> I mentioned C++ std::atomic and Boost.Atomic before. Those need variable >> sized futexes. > > And has anyone converted them to use this new api to see if it works > well or not? > > As was pointed out to me numerous times when I tried to propose > readfile(), you need a real user that can show and prove it is needed > before we can take new syscalls, especially complex beasts like this > one. André has mentioned that he tested the patch set with patched Wine and glibc. I didn't patch Boost.Atomic or std::atomic, but it doesn't look to be problematic. The only difference it would make there is to enable futex2-based implementation for multiple atomic sizes and set up flags to indicate the futex size, instead of only enabling futex-based implementation for 32-bit atomics.