[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAP-5=fW+S3UoqzUc7_+ZmaAj1b=0RtF5p9WHzw23t2AoWZGd9Q@mail.gmail.com>
Date: Mon, 11 Jul 2022 09:16:30 -0700
From: Ian Rogers <irogers@...gle.com>
To: Peter Zijlstra <peterz@...radead.org>
Cc: Anshuman Khandual <anshuman.khandual@....com>,
James Clark <james.clark@....com>,
linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...hat.com>,
Arnaldo Carvalho de Melo <acme@...nel.org>,
Mark Rutland <mark.rutland@....com>,
linux-perf-users@...r.kernel.org
Subject: Re: [PATCH] perf/core: Add macros for possible sysctl_perf_event_paranoid
values
On Mon, Jul 11, 2022 at 5:19 AM Peter Zijlstra <peterz@...radead.org> wrote:
>
> On Mon, Jul 11, 2022 at 02:55:12PM +0530, Anshuman Khandual wrote:
> > Enumerating [-1, 0, 1, 2] paranoid range values in kernel too, does not add
> > much value as well ?
>
> That's what the user-interface requires as well. How is obscuring the
> values the user has to explicitly poke in help things?
Perhaps a helper function like ParanoidAndNotRoot that takes the
failing paranoia level such as here:
https://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git/tree/tools/perf/tests/shell/stat+csv_output.sh?h=perf/core#n48
would help clean this up. Perhaps something that explicitly calls out
this is a permissions check. Cleaning up permission checking seems
like useful value add. We've been trying to do something similar in
tests to make them skip rather than fail due to permission issues -
this should increase the signal perf test gives.
Thanks,
Ian
Powered by blists - more mailing lists