Received: by 2002:ad5:4acb:0:0:0:0:0 with SMTP id n11csp644073imw; Thu, 14 Jul 2022 08:13:08 -0700 (PDT) X-Google-Smtp-Source: AGRyM1sEYGqWYbzPgkWTFiTrJSaEYm04YLJU8MqueN/Bl2na2tC7uHdrLxqVJ4ewOTRfdBYZzKh7 X-Received: by 2002:a17:907:d05:b0:6f4:3729:8e36 with SMTP id gn5-20020a1709070d0500b006f437298e36mr9354036ejc.475.1657811588514; Thu, 14 Jul 2022 08:13:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1657811588; cv=none; d=google.com; s=arc-20160816; b=bJQBtVzCE3ZU4Y6utZ9buM42ZEsBq+1O0S1x6kO30dEbu5dVRu3PTOZYJ2eYEqV7p6 G0kANUm1rmt+/7geHZu/C2oLrleErV0B4F2B4+s9kYX1/yHERi4vbmDPPMRVZBtHcFg9 b0SmZLIyGWzcB5oGselRQtMpTkgssaUz8EAQN9vqV65fRfGxNESRSSJIhLosI547Z8mo IeBhMMYs+kZAjlheRUzAFTaeVvaBS1RkpIi3Lqqxhte8M9OhF06C9pazbAPVODh1xgMp m+duA7Ni/SSc7qg2SO3AX1SQDm56PVhkhv9fRJkq90/QHzwBXenlfZ9sK0md3aqNsfsC qloA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:content-language:subject:user-agent:mime-version :date:message-id:dkim-signature; bh=SD+E46jleghc1zhKhR9PveNf5aZVNxzYDkkNEuLw6xs=; b=mWAbueNfvtfLmrFw660GabRUUNYghsaTCL9ocwe7kBVErbs0C6gWGb0VyKdCkQaKKj VRrTPJ388o+G1wvDYDkJJwkrkG4C2Z/8L1M6aKFwQLczClr8m3tJ+mA+pbEdq4VWvMyP 4Sg0yO3kOaam5qyq4Wci88TWA7vEdIGhLwOSAJuOaPk32bPrPXlT4kVvYCpdfNsNDLFq 1/Bt0DBUBo6tLkGJolPUPkRGT+4fOv3sWQ4VE6r2Opcvw0+qMI/hzZpfWmQlRyRWgWlh pdIBOikzjMz+Gt8RQbvi3PRixucIYpXhUICbRJBvd+tjfauBxQ7aB2XFV4PcaVN8TgdP 69mA== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@igalia.com header.s=20170329 header.b=jPDf1sXv; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id l20-20020aa7c314000000b0043a7438d5b8si2054029edq.104.2022.07.14.08.12.42; Thu, 14 Jul 2022 08:13:08 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=fail header.i=@igalia.com header.s=20170329 header.b=jPDf1sXv; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239825AbiGNPB1 (ORCPT + 99 others); Thu, 14 Jul 2022 11:01:27 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39450 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S239817AbiGNPB0 (ORCPT ); Thu, 14 Jul 2022 11:01:26 -0400 Received: from fanzine2.igalia.com (fanzine.igalia.com [178.60.130.6]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A2EF45E33B; Thu, 14 Jul 2022 08:01:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=igalia.com; s=20170329; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From: References:Cc:To:Subject:MIME-Version:Date:Message-ID:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=SD+E46jleghc1zhKhR9PveNf5aZVNxzYDkkNEuLw6xs=; b=jPDf1sXvRlPt3kdJgvEDxX2uey IoOgOI2HYUqGtfmOWtAn/eLsTaubeRmEpDtlThTCaZPwh0qo4P1axzKtPseySrD5Z6TKVVf6Gx+J8 gwHyY7HD7pLZ1C4EqAV8nJIwcWGj3NENks9j2m0vCDOYMwuT0t/E8/6AY7TNYUuCW6X3CRo4Li2Mg xHCkAj6UAHswTSl4wssGSfxEJ09ev0/AyK87B61JTyjy5th087ygs0og9jduneGmc4yOxzyUrwNim vtVDigEUVgARQqcOg7FQ/RTTbMkFszxNB9lNYZHadrXPaLU5tdUk2FYt8K8vRzOMUWBB0z3KTOu63 yl6BYIoA==; Received: from [177.139.47.106] (helo=[192.168.15.109]) by fanzine2.igalia.com with esmtpsa (Cipher TLS1.3:ECDHE_X25519__RSA_PSS_RSAE_SHA256__AES_128_GCM:128) (Exim) id 1oC0L8-00GV8X-3S; Thu, 14 Jul 2022 17:01:18 +0200 Message-ID: <8bfd13a7-ed02-00dd-63a1-7144f2e55ef0@igalia.com> Date: Thu, 14 Jul 2022 12:00:59 -0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0 Subject: Re: [RFC] futex2: add NUMA awareness Content-Language: en-US To: Andrey Semashev Cc: linux-api@vger.kernel.org, fweimer@redhat.com, linux-kernel@vger.kernel.org, Darren Hart , Peter Zijlstra , Ingo Molnar , Thomas Gleixner , libc-alpha@sourceware.org, Davidlohr Bueso , Steven Rostedt , Sebastian Andrzej Siewior References: <36a8f60a-69b2-4586-434e-29820a64cd88@igalia.com> <74ba5239-27b0-299e-717c-595680cd52f9@gmail.com> From: =?UTF-8?Q?Andr=c3=a9_Almeida?= In-Reply-To: <74ba5239-27b0-299e-717c-595680cd52f9@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,SPF_HELO_NONE, SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Andrey, Thanks for the feedback. Às 08:01 de 14/07/22, Andrey Semashev escreveu: > On 7/14/22 06:18, André Almeida wrote: [...] >> >> Feedback? Who else should I CC? > > Just a few questions: > > Do I understand correctly that notifiers won't be able to wake up > waiters unless they know on which node they are waiting? > If userspace is using NUMA_FLAG, yes. Otherwise all futexes would be located in the default node, and userspace doesn't need to know which one is the default. > Is it possible to wait on a futex on different nodes? Yes, given that you specify `.hint = id` with the proper node id. > > Is it possible to wake waiters on a futex on all nodes? When a single > (or N, where N is not "all") waiter is woken, which node is selected? Is > there a rotation of nodes, so that nodes are not skewed in terms of > notified waiters? Regardless of which node the waiter process is running, what matter is in which node the futex hash table is. So for instance if we have: struct futex32_numa f = {.value = 0, hint = 2}; And now we add some waiters for this futex: Thread 1, running on node 3: futex_wait(&f, 0, FUTEX_NUMA | FUTEX_32, NULL); Thread 2, running on node 0: futex_wait(&f, 0, FUTEX_NUMA | FUTEX_32, NULL); Thread 3, running on node 2: futex_wait(&f, 0, FUTEX_NUMA | FUTEX_32, NULL); And then, Thread 4, running on node 3: futex_wake(&f, 2, FUTEX_NUMA | FUTEX_32); Now, two waiter would wake up (e.g. T1 and T3, node 3 and 2) and they are from different nodes. futex_wake() doesn't provide guarantees of which waiter will be selected, so I can't say which node would be selected. There's no policy for fairness/starvation for futex_wake(). Do you think this would be important for the NUMA case? Let me know if this clarifies your questions.