[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.21.1912271327320.4876@macbook-air>
Date: Fri, 27 Dec 2019 13:31:29 -0500 (EST)
From: Vince Weaver <vincent.weaver@...ne.edu>
To: Arnaldo Carvalho de Melo <arnaldo.melo@...il.com>
cc: Namhyung Kim <namhyung@...nel.org>, Ingo Molnar <mingo@...nel.org>,
Peter Zijlstra <a.p.zijlstra@...llo.nl>,
Jiri Olsa <jolsa@...hat.com>,
Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
Mark Rutland <mark.rutland@....com>,
Stephane Eranian <eranian@...gle.com>,
LKML <linux-kernel@...r.kernel.org>,
linux-perf-users <linux-perf-users@...r.kernel.org>,
Tejun Heo <tj@...nel.org>, Li Zefan <lizefan@...wei.com>,
Johannes Weiner <hannes@...xchg.org>,
Adrian Hunter <adrian.hunter@...el.com>, mtk.manpages@...il.com
Subject: Re: [PATCHSET 0/9] perf: Improve cgroup profiling (v3)
On Thu, 26 Dec 2019, Arnaldo Carvalho de Melo wrote:
> Em Tue, Dec 24, 2019 at 09:40:04AM +0900, Namhyung Kim escreveu:
> > On Tue, Dec 24, 2019 at 2:35 AM Vince Weaver <vincent.weaver@...ne.edu> wrote:
> > > On Mon, 23 Dec 2019, Namhyung Kim wrote:
> > > > This work is to improve cgroup profiling in perf. Currently it only
> > > > supports profiling tasks in a specific cgroup and there's no way to
> > > > identify which cgroup the current sample belongs to. So I added
> > > > PERF_SAMPLE_CGROUP to add cgroup id into each sample. It's a 64-bit
> > > > integer having file handle of the cgroup. And kernel also generates
> > > > PERF_RECORD_CGROUP event for new groups to correlate the cgroup id and
> > > > cgroup name (path in the cgroup filesystem). The cgroup id can be
> > > > read from userspace by name_to_handle_at() system call so it can
> > > > synthesize the CGROUP event for existing groups.
>
> > > so is there a patch to the manpage that describes this new behavior in
> > > perf_event_open()?
>
> > Not yet. I'll cook a patch once it's merged to the Linus' tree.
>
> Vince, was it ever considered to carry the man page in the kernel
> sources and then make it so that new features need to come with the
> respective changes to the man page? I think that would be a good move,
> you would be the maintainer for that file, what do you think?
While I do a lot of work on the perf_event_open() manpage, it's part of
the linux man-pages project so I don't really control where it is
maintained.
I personally do not think it would help much merging into the kernel tree.
I still think the idea of moving everything into linux-git (such as the
"perf" tool) isn't always the best idea and can make it harder for people
who aren't kernel developers to work on things.
Vince
Powered by blists - more mailing lists