From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com [IPv6:2a00:1450:4864:20::12d]) by sourceware.org (Postfix) with ESMTPS id 2F127383F40B for ; Tue, 8 Jun 2021 11:03:54 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 2F127383F40B Received: by mail-lf1-x12d.google.com with SMTP id i10so31426322lfj.2 for ; Tue, 08 Jun 2021 04:03:54 -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=pbvnIUDlmrsEz7h8hsEn+CaTGHHdDs7PDJp6JoerDy8=; b=FGk95KEgkXFMuONt0EcleC5ox8ytxP0GEGLJtXBwiOsUDx/C5mEZNGf4QxVmxAcRIv nqS4oP9almbQ08NI8pClmGIIL4x3ujyYbpnlAgIrBv5E20+FB/zDxAZhNKUXs6CePqta oe6Diicw9wygnRGeUpZ1Zq/i1B5ow5Y1La7ITF+xInAF+XdiwJjTwPOROWnMU9CgMK1u oaT0EBFQM6YaUWv+3YIqxib/G8M8YB0xXIl2TxYiuu2g3WwUC4ph9AEsCWgSVgwvL2MC BbqPjLEym5Wjc+t1O2/yTTSfWahyaOixo9ZLeJhSk+PJS5W2ZeW/dixcFx9+7wEUgnCy 9S4g== X-Gm-Message-State: AOAM531zn+qxnRnLhCu8d1Sw7C+xAGjNvKE9/lWns/hSe94VZ+JItItW SPXaj8btuCOTofrTCtRAZKQ= X-Google-Smtp-Source: ABdhPJxY4clPUf+kJEyTCGanb9QmdPfQfH9en2/Ins7WQwtCUTKyOZIBj5brYMql77/RoBELy+eFOw== X-Received: by 2002:ac2:43a3:: with SMTP id t3mr3746636lfl.183.1623150233042; Tue, 08 Jun 2021 04:03:53 -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 x8sm1805778lfn.186.2021.06.08.04.03.51 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 08 Jun 2021 04:03:52 -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> <6d8e3bb4-0cef-b991-9a16-1f03d10f131d@gmail.com> <1622980258.cfsuodze38.astroid@bobo.none> <1623114630.pc8fq7r5y9.astroid@bobo.none> From: Andrey Semashev Message-ID: Date: Tue, 8 Jun 2021 14:03:50 +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: <1623114630.pc8fq7r5y9.astroid@bobo.none> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.4 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 11:03:55 -0000 On 6/8/21 4:25 AM, Nicholas Piggin wrote: > > Are shared pthread mutexes using existing pthread APIs that are today > implemented okay with futex1 system call a good reason to constrain > futex2 I wonder? Or do we have an opportunity to make a bigger change > to the API so it suffers less from non deterministic latency (for > example)? If futex2 is not able to cover futex1 use cases then it cannot be viewed as a replacement. In the long term this means futex1 cannot be deprecated and has to be maintained. My impression was that futex1 was basically unmaintainable(*) and futex2 was an evolution of futex1 so that users of futex1 could migrate relatively easily and futex1 eventually removed. Maybe my impression was wrong, but I would like to see futex2 as a replacement and extension of futex1, so the latter can be deprecated at some point. In any case, creating a new API should consider requirements of its potential users. If futex2 is intended to eventually replace futex1 then all current futex1 users are potential users of futex2. If not, then the futex2 submission should list its intended users, at least in general terms, and their requirements that led to the proposed API design. (*) I use "unmaintainable" in a broad sense here. It exists and works in newer kernel versions and may receive code changes that are necessary to keep it working, but maintainers refuse any extensions or modifications of the code, mostly because of its complexity.