linux-kernel - Re: [PATCH v4 00/10] riscv: Allow userspace to directly access perf counters

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAOnJCUKCx0Jh1igZytKAYePhhUBt=x5ANCVx4FRTbLtxGkyowA@mail.gmail.com>
Date:   Wed, 19 Jul 2023 10:14:36 -0700
From:   Atish Patra <atishp@...shpatra.org>
To:     Rémi Denis-Courmont <remi@...lab.net>
Cc:     linux-riscv@...ts.infradead.org, linux-kernel@...r.kernel.org,
        Aurelien Jarno <aurelien@...el32.net>,
        Mathieu Malaterre <malat@...ian.org>,
        Jan Newger <jannewger@...gle.com>
Subject: Re: [PATCH v4 00/10] riscv: Allow userspace to directly access perf counters

On Wed, Jul 19, 2023 at 7:46 AM Rémi Denis-Courmont <remi@...lab.net> wrote:
>
> Le keskiviikkona 19. heinäkuuta 2023, 1.48.49 EEST Atish Patra a écrit :
> > > Isn't RDTIM susceptible to interference from power management and CPU
> > > frequency scaling? I suppose that RDCYCLE may behave differently depending
> > > on PM in *some* designs, but that would still be way better than RDTIME
> > > for the purpose.
> >
> > Yes. But that's what it is probably using for other ISAs ?
>
> At least on AArch64, it is using either Linux perf cycle counter, or if that
> is disabled at build time, the raw PMU cycle counter - which obviously leads
> to SIGILL on Linux, just like this MR would do with RDCYCLE.
>

Good to know. Thanks for the clarification.

> Again, I do not *personally* have objections to disabling RDCYCLE for
> userspace (somebody else does, but that's neither my nor your problem). I do
> have objections to the wording of some of the commit messages though.
>

Completely agreed. We will update the commit text with more clarification in v5.

> > My point was it should just do whatever it does for other ISA. RISC-V is no
> > special in that regard.
>
> Sure. My point is that RDTIME may be great for, so to say, system-level
> benchmarks. For FFmpeg that could something like how long it takes to
> transcode a video. But it doesn't seem to make much sense for
> microbenchmarking of single threaded tightly optimised loops, as opposed to
> RDCYCLE (or a wrapper for RDCYCLE).
>
> --
> Rémi Denis-Courmont
> http://www.remlab.net/
>
>
>


-- 
Regards,
Atish