From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-il1-x130.google.com (mail-il1-x130.google.com [IPv6:2607:f8b0:4864:20::130]) by sourceware.org (Postfix) with ESMTPS id 73626388E81C for ; Fri, 4 Jun 2021 04:51:44 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 73626388E81C Received: by mail-il1-x130.google.com with SMTP id r6so7716098ilj.1 for ; Thu, 03 Jun 2021 21:51:44 -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=1PgbPrY10zYsjifCFzWyh2BDHPVeu66kYt4xk+1XagA=; b=LKF/M+quHf49+EMjZeoTEZRVrfJHzsYBmvjYUSI7K8LBIMl86Bz2DeZYDztNA62SL1 hW/mPctFCe/4yatJPxKUOHdcbvcHdrqeTJLGsXug/Xb586AUQ1TOJRVptZwvxWCpPYZ5 71kMk1tR2i6ej5k2jAz7X1AORiNRTPBNiFjmOKUt9Urh3L0rt3/Ul0KkUuN1vThryKHA SnyznVcm8y3kJtCpm9x8NNfdSAwEdGPh6bMPpVeHCNtjIR7f9T1UBXZqjxYAT1u39K9F Ek5UCR6aiFqFiwELnKV5wFRrCtiZtkRlkJq3MDmt9EQ/VO1tL1pRUbkjKj7IWqHvVJ9s /qLQ== X-Gm-Message-State: AOAM532K2mNdY9c3ukqFMUr7IidmQxA11c0ATOvu1iP49677FXUBVjks UTypBKExfIzai49opsCotzU= X-Google-Smtp-Source: ABdhPJy3sgFV/xsccZqhNRUor2dII2d6E1DIQNG12H/xDoszibp8FHPgZBX0ThCCy6cLblI5uHY9AA== X-Received: by 2002:a05:6e02:10d4:: with SMTP id s20mr2397773ilj.37.1622782303991; Thu, 03 Jun 2021 21:51:43 -0700 (PDT) Received: from ?IPv6:2606:3280:8:e29:2093:3298:f887:8ed6? ([2606:3280:8:e29:2093:3298:f887:8ed6]) by smtp.googlemail.com with ESMTPSA id s23sm2762345iol.49.2021.06.03.21.51.42 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 03 Jun 2021 21:51:43 -0700 (PDT) Subject: Re: [PATCH v4 00/15] Add futex2 syscalls To: =?UTF-8?Q?Andr=c3=a9_Almeida?= , Thomas Gleixner , Ingo Molnar , Peter Zijlstra , Darren Hart , linux-kernel@vger.kernel.org, Steven Rostedt , Sebastian Andrzej Siewior Cc: kernel@collabora.com, krisman@collabora.com, pgriffais@valvesoftware.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, Peter Oskolkov , Andrey Semashev , Davidlohr Bueso References: <20210603195924.361327-1-andrealmeid@collabora.com> From: Zebediah Figura Message-ID: Date: Thu, 3 Jun 2021 23:51:41 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: <20210603195924.361327-1-andrealmeid@collabora.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-3.8 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_ENVFROM_END_DIGIT, FREEMAIL_FROM, KAM_MANYTO, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham 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: Fri, 04 Jun 2021 04:51:45 -0000 On 6/3/21 2:59 PM, André Almeida wrote: > ** The wait on multiple problem > > The use case lies in the Wine implementation of the Windows NT interface > WaitMultipleObjects. This Windows API function allows a thread to sleep > waiting on the first of a set of event sources (mutexes, timers, signal, > console input, etc) to signal. Considering this is a primitive > synchronization operation for Windows applications, being able to quickly > signal events on the producer side, and quickly go to sleep on the > consumer side is essential for good performance of those running over Wine. > I know this is part of the cover letter, but I really do want to clarify that this isn't really accurate. The use case that this is referring to is not "the Wine implementation of WaitForMultipleObjects", it is an out-of-tree implementation of WaitForMultipleObjects that provides improved performance compared to the in-tree implementation. This is especially salient because: (1) this out-of-tree implementation is only in a small handful of cases any more performant than a different out-of-tree implementation which uses eventfd and poll() instead; (2) these implementations will remain out-of-tree due to compatibility and robustness problems; (3) I believe there is potential for an upstreamable implementation which does not rely on futex or futex2.