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;
MIME-Version: 1.0
References: <20230703124647.215952-1-alexghiti@rivosinc.com>
 <4761144.fSbbhVQpq0@basile.remlab.net> <CAOnJCUJreDYWZcSRr-pb1vwRg_LyU7TBG+b_9Ys8rVmM8_fvgA@mail.gmail.com>
 <8756384.Zvl9fuB8X0@basile.remlab.net>
In-Reply-To: <8756384.Zvl9fuB8X0@basile.remlab.net>
From:   Atish Patra <atishp@atishpatra.org>
Date:   Tue, 18 Jul 2023 15:48:49 -0700
Message-ID: <CAOnJCU+W9u+HnMfjU_y9W7331Zx07eQs9R1twV0=KsBAeSMSjw@mail.gmail.com>
Subject: Re: [PATCH v4 00/10] riscv: Allow userspace to directly access perf counters
To:     =?UTF-8?Q?R=C3=A9mi_Denis=2DCourmont?= <remi@remlab.net>
Cc:     linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org,
        Aurelien Jarno <aurelien@aurel32.net>,
        Mathieu Malaterre <malat@debian.org>,
        Jan Newger <jannewger@google.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Tue, Jul 18, 2023 at 12:04=E2=80=AFPM R=C3=A9mi Denis-Courmont <remi@rem=
lab.net> wrote:
>
> Le tiistaina 18. hein=C3=A4kuuta 2023, 21.45.15 EEST Atish Patra a =C3=A9=
crit :
> > > I agree that it's not only insecure but also incorrect. However it mo=
stly
> > > works. In fact I don't disagree with the change as such, but I think =
that
> > > the commit messages are misleading and confusing. For a start, in one
> > > place it says that it is not breaking user space and in another it sa=
ys
> > > basically the opposite.
> >
> > Agreed. We will improve the commit message to clarify that. That's also=
 the
> > reason I started this whole thread :)
> >
> > > (Unfortunately, not everybody agrees with the change. I can't seem to=
 get
> > > FFmpeg's checkasm tool fixed:
> > > http://ffmpeg.org/pipermail/ffmpeg-devel/2023-July/312245.html )
> >
> > Why can't rdtime(equivalent of rdtsc) be used instead of rdcycle ?
>
> Isn't RDTIM susceptible to interference from power management and CPU
> frequency scaling? I suppose that RDCYCLE may behave differently dependin=
g 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 ? My point
was it should
just do whatever it does for other ISA. RISC-V is no special in that regard=
.

> As far as benchmarking is concerned (_excluding_ system security), RDTIME
> seems to have all the problems of RDCYCLE, and then some more, no?
>

Correct. If the application can deal with noisy data, it can use
rdtime similar to
other architectures. Otherwise, it should just use the perf mmap
interface in the beginning
and read the counters whenever required.

> > The perf syscall overhead is just one time setup thing during the
> > start of the application.
> > For counting the cycles before/after a loop, it still provides a
> > direct CSR access in user mode.
>
> I suppose that you allude to mmap() here? The (dumb) FFmpeg code is using=
 the
> ioctl() interface though, but that's just laziness.
>

Yeah. I agree it is more work but just one time effort to get more
reliable data without
compromising the security.

> --
> =E3=83=AC=E3=83=9F=E3=83=BB=E3=83=87=E3=83=8B-=E3=82=AF=E3=83=BC=E3=83=AB=
=E3=83=A2=E3=83=B3
> http://www.remlab.net/
>
>
>


--=20
Regards,
Atish