Received: by 2002:a05:6a11:4021:0:0:0:0 with SMTP id ky33csp1052910pxb; Wed, 15 Sep 2021 21:12:59 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwEd8QTyS6ZtO4X8BsK93LBlb6Q4Ows6EH8IXDQ6VYzTQZILtZvSU/kXS714G4yQNpWGeWF X-Received: by 2002:a05:6402:27c6:: with SMTP id c6mr4022922ede.111.1631765578938; Wed, 15 Sep 2021 21:12:58 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1631765578; cv=none; d=google.com; s=arc-20160816; b=Nm4tOGU2beuChsU7hpvnLm0yUy0r9QnYYjO4jOfyRtNj2EBpAYAVQERewsQx6T1v2d NXmg+moheOwEvztZ9m4A0rTVZlLGe2YNiJ5H63RY71mOHMUyBmiW0OhXi4d3FIbvCChb TLNJk+LQNUH/atx1isImjCwhvVsnGm1y5e6k5sElcadd/aiMtR6qTwcjEy93ynIa1FO+ l+Da/cWhMAXz5NfN/LT7sYKB2q51AinMMI48cm99yq8WoSHJEK47/mXG1DgpHZy9pZxe 4KfNQzV3huA9f/DT7ojLrOsmRhUvckFtiq1Cnf+K+KbIAgj9cJJMVZ57Y9ylxTN/X14i 2ZQw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:message-id:in-reply-to:date:references:organization :subject:cc:to:from; bh=BoJfVaV9NuYamoQPUm5MwhS0b4pMx7lTPdyuFt99WaQ=; b=yCutuDcefLh/UgBtAd8wSYe5vCvYeRj3WmM1JiuwfKRovt2vLwC2tCfWKkYeCWW5CT d6XX69i74/TXIB4g63zWVcKjwfrHWamiEgzYpGX8NcALphPkNY91agG466OgzB86zOSX VN0giIkXjshZcjarOzkT9UsBBQ37yNhRzQYFq3mQwwKCPxXdGtE6mqgR5vcdIYh9RBko JjcjZw21zguhvCwB2Oj899xLH7gRyLkokik7FeTxItJJhMf7Mnn4d62JeLs7Jyl53h41 hXchUCAhZF1TFOdzOAyepc49tu16ZcmjvlDXrQ2SQsfayATilvJIaopdY4huV1afz2dL DZUQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=collabora.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id q22si2254934edc.295.2021.09.15.21.12.32; Wed, 15 Sep 2021 21:12:58 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=collabora.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229904AbhIPELw convert rfc822-to-8bit (ORCPT + 99 others); Thu, 16 Sep 2021 00:11:52 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47950 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229463AbhIPELv (ORCPT ); Thu, 16 Sep 2021 00:11:51 -0400 Received: from bhuna.collabora.co.uk (bhuna.collabora.co.uk [IPv6:2a00:1098:0:82:1000:25:2eeb:e3e3]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A0530C061574; Wed, 15 Sep 2021 21:10:31 -0700 (PDT) Received: from localhost (unknown [IPv6:2a00:5f00:102:0:f4d2:afff:fe2b:18b5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: krisman) by bhuna.collabora.co.uk (Postfix) with ESMTPSA id 161211F435AC; Thu, 16 Sep 2021 05:10:28 +0100 (BST) From: Gabriel Krisman Bertazi To: =?utf-8?Q?Andr=C3=A9?= Almeida Cc: Thomas Gleixner , Ingo Molnar , Peter Zijlstra , Darren Hart , linux-kernel@vger.kernel.org, Steven Rostedt , Sebastian Andrzej Siewior , kernel@collabora.com, linux-api@vger.kernel.org, libc-alpha@sourceware.org, mtk.manpages@gmail.com, Davidlohr Bueso , Arnd Bergmann Subject: Re: [PATCH v3 2/6] futex2: Implement vectorized wait Organization: Collabora References: <20210913175249.81074-1-andrealmeid@collabora.com> <20210913175249.81074-3-andrealmeid@collabora.com> <875yv4ge83.fsf@collabora.com> <58536544-e032-1954-ce30-d131869dc95e@collabora.com> Date: Thu, 16 Sep 2021 00:10:25 -0400 In-Reply-To: <58536544-e032-1954-ce30-d131869dc95e@collabora.com> (=?utf-8?Q?=22Andr=C3=A9?= Almeida"'s message of "Tue, 14 Sep 2021 14:18:58 -0300") Message-ID: <8735q5dutq.fsf@collabora.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org André Almeida writes: >>> +/** >>> + * struct futex_waitv - A waiter for vectorized wait >>> + * @val: Expected value at uaddr >>> + * @uaddr: User address to wait on >>> + * @flags: Flags for this waiter >>> + * @__reserved: Reserved member to preserve data alignment. Should be 0. >>> + */ >>> +struct futex_waitv { >>> + __u64 val; >>> + __u64 uaddr; >>> + __u32 flags; >>> + __u32 __reserved; >>> +}; >> >> why force uaddr to be __u64, even for 32-bit? uaddr could be a (void*) for >> all we care, no? Also, by adding a reserved field, you are wasting 32 >> bits even on 32-bit architectures. >> > > We do that to make the structure layout compatible with both entry > points, remove the need for special cast and duplicated code, as > suggested by Thomas and Arnd: > > https://lore.kernel.org/lkml/87v94310gm.ffs@tglx/ > > https://lore.kernel.org/lkml/CAK8P3a0MO1qJLRkCH8KrZ3+=L66KOsMRmcbrUvYdMoKykdKoyQ@mail.gmail.com/ I find this weird. I'm not even juts talking about compat, but even on native 32-bit. But also, 32 applications on 64, which is a big use case for games. The structure is mandating a 64 bit uaddr field and has an unnecessary pad. You are wasting 20% of the space, which is gonna be elements of a vector coming from user space. Worst case, you are doing copy_from_user of an extra 1k bytes in the critical path of futex_waitv for no good reason. Also, if I understand correctly, Arnd suggestion, at least, was to have two parser functions and a single syscall entry point, that would do the translation: if (in_compat_syscall()) futex_parse_waitv_compat(futexv, waiters, nr_futexes); else futex_parse_waitv(futexv, waiters, nr_futexes); -- Gabriel Krisman Bertazi