linux-kernel - Re: [RFC] perf: Add "-f" and "-F" flags to watch a "/sys" style file

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] [day] [month] [year] [list]

Message-ID: <20170516174225.gx3xate4dbg2zgqj@intel.com>
Date:   Tue, 16 May 2017 10:42:25 -0700
From:   "Luck, Tony" <tony.luck@...el.com>
To:     Arnaldo Carvalho de Melo <acme@...nel.org>
Cc:     Vikas Shivappa <vikas.shivappa@...el.com>,
        Stephane Eranian <eranian@...gle.com>,
        David Carrillo-Cisneros <davidcc@...gle.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Ingo Molnar <mingo@...hat.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
        linux-kernel@...r.kernel.org
Subject: Re: [RFC] perf: Add "-f" and "-F" flags to watch a "/sys" style file

On Mon, May 15, 2017 at 09:45:58PM -0300, Arnaldo Carvalho de Melo wrote:
> I haven't been following the discussion about the resctrl fs discussion
> to understand why those values couldn't be read via
> sys_perf_event_open(), so can't comment on that, but the implementation
> on the tools/ classes look nice, i.e. -e will get perf_evsel instances
> that interface with the kernel via sys_perf_event_open(), -f/-F will get
> perf_evsel instances that read values via the rsctrl file system, clean.

It's kind of tortuous to connect the dots from these events to
sys_perf_event_open().  That has a strong connection to a specific
task, and/or a specific CPU.  But these events count for a group of
tasks and the resource is shared typically at the socket level.

E.g. we might have three "jobs" (each consisting of several processes/threads).
We run them all in a shared restricted cache allocation environment, but
wanto to measure how each is performing:

# cd /sys/fs/resctrl
# mkdir cg1
# echo $$ > cg1/tasks
#
# echo "L3:0=ff000;1=ff000" > cg1/schemata
# mkdir cg1/mon_tasks/j1 cg1/mon_tasks/j2 cg1/mon_tasks/j3
#
# echo $$ > cg1/mon_tasks/j1/tasks
# job1 &
# echo $$ > cg1/mon_tasks/j2/tasks
# job2 &
# echo $$ > cg1/mon_tasks/j3/tasks
# job3 &

Now we can view the cache occupancy for each of job1, job2, and job3 via
some files[*] in each of these directories. Or see the summary cache occupancy
for all three jobs via files in the control group (/sys/fs/resctrl/cg1)
For me, I can easily see how to use "-f" options to look at the right
files to get the information I want.

Offline we've talked at the white board level of either over-loading the
"-G" flag used for Cgroups, or adding a new "-R" flag for resctrl groups
and then having our internal kernel code respond to sys_perf_event_open()
with a file descriptor that behaves like other "perf" file descriptors.
Maybe someone will work out the syntax wrinkles to express that on
the perf command line. Perhaps something like:

# perf stat -e intel/llc_occupancy -R /sys/fs/resctrl/cg1/mon_tasks/j1 ...

The "intel/llc_occupancy" event would need some special attributes so
that perf would know that it requires "-R" option(s) too, and doesn't
work with other options like "-C".

> P.S. I may be slow to reply because I'm on vacation till the end of this
> month.

Thanks for looking at this while on vacation. Now exit e-mail and enjoy
your time off :-)

-Tony

[*] exact names still in flux, and will probably change again when
    we post patches and people who are better at choosing names begin
    to review then.