Received: by 2002:a05:6a10:5bc5:0:0:0:0 with SMTP id os5csp955237pxb; Tue, 19 Oct 2021 17:04:12 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzkVK1jbl7k0RYF8hMnG+9AXv2vKtlLxdTzeeL0Arcuv1HtOYGxf1GuHNDH44mzS0Y0gVCJ X-Received: by 2002:a05:6402:1a56:: with SMTP id bf22mr47608662edb.208.1634688252509; Tue, 19 Oct 2021 17:04:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1634688252; cv=none; d=google.com; s=arc-20160816; b=VHmuPyJYqB4v1Wd3irdjjykNqBPsH34enpG705vTi+WxU5eHWmblmgg4qvZ3wnCbAp VngzK6exAQd6PoliHfC2BRQTyPdEqQxDIP9p6HCoAGlE8rJoyaRBQIlPgfgJ+snOl+Uw 2X7+X2S5nW3nCak/4Ge4xD4f0cgbRU5H5Y/jEVgrFYzFvwX0JIpr6OOI2+ERsqzf1vSa TE846rhTEqshZrlBwE6/7jaW6GorssCNIR2ws6b6PwNGoYRbLmIewZ1e9c810AsfL9Hi jigebtdF0rXgOOrBrKrgqI/sXxmPkkZpRG1hOrCgDVPfiG4T/ek5N3lvCYvpt7QVYZ9J i5Jg== 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; bh=GV/hFc6oM8qAdxlzGADOqtpxY+IZnyLZsNTP/OV5Tf8=; b=VpOHHcFJg/Vjct9HsMFfhahdTy9m6fzXamMbir2/7npuHr9+9Shb3ysJTWIVgj6Vdu yFGm69ko2NZgJJQXmeLTpB8utRVgCsxiEFBT6iLK61DIL9uWkLKQg0ccmRWT0htQpwP1 cyLViASidbZjrL8FWdxtoDsFTUKTBldExo9iA5vI+MidswuAzD+u9h97qnROwOcTBBtG Me6lDfIhrgmwL0ygziN74jzhYHJhgCjy2sdRnB36mFcYclwJulTm7tVOCharrRchd2fq Y+T8Yv3HqwlZjsAty9xmxzn9yXn6qOYXfmsZwrax3CV54iRYtHcea/Dht5u9TSDygPTl VbzA== 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 m10si638656ejb.115.2021.10.19.17.03.48; Tue, 19 Oct 2021 17:04:12 -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 S229707AbhJTAEH (ORCPT + 99 others); Tue, 19 Oct 2021 20:04:07 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54414 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229602AbhJTAEG (ORCPT ); Tue, 19 Oct 2021 20:04:06 -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 6087FC06161C; Tue, 19 Oct 2021 17:01:53 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) (Authenticated sender: tonyk) with ESMTPSA id 8D6C01F43E27 Message-ID: <0d55b0a0-dd8c-0494-a200-7acb1976e32a@collabora.com> Date: Tue, 19 Oct 2021 21:01:41 -0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.2.0 Subject: Re: [PATCH v2 1/2] perf bench futex: Use a 64-bit time_t Content-Language: en-US To: Alistair Francis Cc: Arnaldo Carvalho de Melo , Alistair Francis , linux-riscv , linux-perf-users@vger.kernel.org, Linux Kernel Mailing List , Namhyung Kim , Jiri Olsa , Alexander Shishkin , Mark Rutland , Davidlohr Bueso , Darren Hart , Peter Zijlstra , Ingo Molnar , Thomas Gleixner , Atish Patra , Arnd Bergmann , Alistair Francis References: <20211015005634.2658470-1-alistair.francis@opensource.wdc.com> From: =?UTF-8?Q?Andr=c3=a9_Almeida?= In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Às 20:17 de 19/10/21, Alistair Francis escreveu: > On Wed, Oct 20, 2021 at 2:56 AM Arnaldo Carvalho de Melo > wrote: >> >> Em Fri, Oct 15, 2021 at 10:56:33AM +1000, Alistair Francis escreveu: >>> From: Alistair Francis >>> >>> Convert tools/perf to only use a 64-bit time_t. On 64-bit architectures >>> this isn't a functional change. On 32-bit architectures we now only >>> perform 64-bit time_t syscalls (__NR_futex_time64) and use a struct >>> timespec64. >>> >>> This won't work on kernels before 5.1, but as perf is tied to the kernel >>> that's ok. >> >> No, perf is not tied to the kernel, one can use a new perf tool on any >> previous kernel, and an old perf tool should work on new kernels as >> well. > > + André, I won't be doing this the way you requested > Ok, thanks anyway for your work and sorry for the trouble :) > Ok, so back to the previous version then. I'll send the patches soon. > > Alistair > >> >> - Arnaldo >> >>> This allows us to build perf for 32-bit architectures with 64-bit time_t >>> like RISC-V 32-bit. >>> >>> Signed-off-by: Alistair Francis >>> --- >>> tools/perf/bench/futex.h | 26 ++++++++++++++++++++------ >>> 1 file changed, 20 insertions(+), 6 deletions(-) >>> >>> diff --git a/tools/perf/bench/futex.h b/tools/perf/bench/futex.h >>> index b3853aac3021c..b9665d43d2988 100644 >>> --- a/tools/perf/bench/futex.h >>> +++ b/tools/perf/bench/futex.h >>> @@ -12,6 +12,7 @@ >>> #include >>> #include >>> #include >>> +#include >>> >>> struct bench_futex_parameters { >>> bool silent; >>> @@ -27,12 +28,14 @@ struct bench_futex_parameters { >>> unsigned int nrequeue; >>> }; >>> >>> +#define timespec64 __kernel_timespec >>> + >>> /** >>> * futex() - SYS_futex syscall wrapper >>> * @uaddr: address of first futex >>> * @op: futex op code >>> * @val: typically expected value of uaddr, but varies by op >>> - * @timeout: typically an absolute struct timespec (except where noted >>> + * @timeout: typically an absolute struct timespec64 (except where noted >>> * otherwise). Overloaded by some ops >>> * @uaddr2: address of second futex for some ops >>> * @val3: varies by op >>> @@ -47,15 +50,26 @@ struct bench_futex_parameters { >>> * These argument descriptions are the defaults for all >>> * like-named arguments in the following wrappers except where noted below. >>> */ >>> -#define futex(uaddr, op, val, timeout, uaddr2, val3, opflags) \ >>> - syscall(SYS_futex, uaddr, op | opflags, val, timeout, uaddr2, val3) >>> +/** >>> + * We only support 64-bit time_t for the timeout. >>> + * On 64-bit architectures we can use __NR_futex >>> + * On 32-bit architectures we use __NR_futex_time64. This only works on kernel >>> + * versions 5.1+. >>> + */ >>> +#if __BITS_PER_LONG == 64 >>> +# define futex(uaddr, op, val, timeout, uaddr2, val3, opflags) \ >>> + syscall(__NR_futex, uaddr, op | opflags, val, timeout, uaddr2, val3) >>> +#else >>> +# define futex(uaddr, op, val, timeout, uaddr2, val3, opflags) \ >>> + syscall(__NR_futex_time64, uaddr, op | opflags, val, timeout, uaddr2, val3) >>> +#endif >>> >>> /** >>> * futex_wait() - block on uaddr with optional timeout >>> * @timeout: relative timeout >>> */ >>> static inline int >>> -futex_wait(u_int32_t *uaddr, u_int32_t val, struct timespec *timeout, int opflags) >>> +futex_wait(u_int32_t *uaddr, u_int32_t val, struct timespec64 *timeout, int opflags) >>> { >>> return futex(uaddr, FUTEX_WAIT, val, timeout, NULL, 0, opflags); >>> } >>> @@ -74,7 +88,7 @@ futex_wake(u_int32_t *uaddr, int nr_wake, int opflags) >>> * futex_lock_pi() - block on uaddr as a PI mutex >>> */ >>> static inline int >>> -futex_lock_pi(u_int32_t *uaddr, struct timespec *timeout, int opflags) >>> +futex_lock_pi(u_int32_t *uaddr, struct timespec64 *timeout, int opflags) >>> { >>> return futex(uaddr, FUTEX_LOCK_PI, 0, timeout, NULL, 0, opflags); >>> } >>> @@ -111,7 +125,7 @@ futex_cmp_requeue(u_int32_t *uaddr, u_int32_t val, u_int32_t *uaddr2, int nr_wak >>> */ >>> static inline int >>> futex_wait_requeue_pi(u_int32_t *uaddr, u_int32_t val, u_int32_t *uaddr2, >>> - struct timespec *timeout, int opflags) >>> + struct timespec64 *timeout, int opflags) >>> { >>> return futex(uaddr, FUTEX_WAIT_REQUEUE_PI, val, timeout, uaddr2, 0, >>> opflags); >>> -- >>> 2.31.1 >> >> -- >> >> - Arnaldo