Messages in this thread | | | Subject | Re: [RFC PATCH 0/2] perf_events: add support for per-cpu per-cgroup monitoring (v3) | From | Peter Zijlstra <> | Date | Wed, 22 Sep 2010 09:25:58 +0200 |
| |
On Wed, 2010-09-22 at 10:04 +0530, Balbir Singh wrote:
> That understanding is correct, but the whole approach sounds more > complex due to several subsystems involved, the expectation is that > we'll move perf to all the correct cgroups for each subsystem.
Well, we'll only move a completely dormant task to a cgroup and out again.
> > > > If we were to fork a child that's simply sitting idle in waitpid() (or > > > > any other blocking syscall) we can move that around cgroup without > > > > affecting the cgroup itself. > > > > > > But then things get a bit more complicated because the perf_event_open() > > > has to be done in that child. File descriptors created in child processes > > > and not shared with their parent. You'd have to pass file descriptors around. > > > That seems overly complicated. > > > > Uhm, no the trick is that the child remains absolutely dormant and > > therefore doesn't accrue any accounting, all you need is a known task in > > the cgroup, the parent can then specify the child pid to identify the > > group. > > > > Once you've opened the counter, you can move the kid out and kill it. > > Note that moving it out of the cgroup before killing it ensure it never > > wakes up inside that cgroup. > > What the benefits of this complexity, not chaning perf_event_attr?
Yes, attach information should not be in _attr. And you avoid the hassle of creating a special file and passing fds to it around.
| |