Messages in this thread | | | Date | Tue, 21 Sep 2010 18:33:38 +0200 | Subject | Re: [RFC PATCH 0/2] perf_events: add support for per-cpu per-cgroup monitoring (v3) | From | Stephane Eranian <> |
| |
On Tue, Sep 21, 2010 at 6:27 PM, Peter Zijlstra <peterz@infradead.org> wrote: > On Tue, 2010-09-21 at 18:17 +0200, Stephane Eranian wrote: >> On Tue, Sep 21, 2010 at 4:03 PM, Peter Zijlstra <peterz@infradead.org> wrote: >> > On Tue, 2010-09-21 at 15:38 +0200, Stephane Eranian wrote: >> >> > Hmm, indeed. One thing we can do about that is move perf into the >> >> > cgroup, create the counter (disabled) using self to identify the cgroup, >> >> > move perf back to where it came from, and enable the counter. >> >> > >> >> Yes, that's another possibility. I wonder if there are any non-obvious >> >> difficulties with this approach. >> > >> > Yes, there is, but I think we can fix it. The problem with moving perf >> > itself around is that perf is not a fully dormant process and can thus >> > interact with the cgroup state. >> > >> I was thinking about memory accounting for instance. > > I think the memory controller only accounts things when the process > actually touches something. A process that never wakes will never touch > anything. > >> > 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. > > Ok, I see. I got confused by the 'self' pid. The parent moves the dormant child into the cgroup and uses its pid in perf_event_open(). The existing logic inside the tool remains unmodified.
I will experiment with this approach.
| |