Re: [PATCH 1/2] perf_events: add support for per-cpu per-cgroup monitoring(v5)

[Li Zefan]

19:28, Peter Zijlstra wrote:
> On Thu, 2010-11-18 at 12:40 +0200, Stephane Eranian wrote:
>> This kernel patch adds the ability to filter monitoring based on
>> container groups (cgroups). This is for use in per-cpu mode only.
>>     
>> The cgroup to monitor is passed as a file descriptor in the pid
>> argument to the syscall. The file descriptor must be opened to 
>> the cgroup name in the cgroup filesystem. For instance, if the
>> cgroup name is foo and cgroupfs is mounted in /cgroup, then the
>> file descriptor is opened to /cgroup/foo. Cgroup mode is
>> activated by passing PERF_FLAG_PID_CGROUP in the flags argument
>> to the syscall.
>>
>> For instance to measure in cgroup foo on CPU1 assuming
>> cgroupfs is mounted under /cgroup:
>>
>> struct perf_event_attr attr;
>> int cgroup_fd, fd;
>>
>> cgroup_fd = open("/cgroup/foo", O_RDONLY);
>> fd = perf_event_open(&attr, cgroup_fd, 1, -1, PERF_FLAG_PID_CGROUP);
>> close(cgroup_fd);
>>
>> Signed-off-by: Stephane Eranian <eranian@xxxxxxxxxx> 
> 
> Could you please split this patch:
>   - pure code movement
>   - time accounting changes
>   - event_filter_match() stuff
>   - cgroup thing
> 
> From a quick reading it doesn't look bad, but I want an ACK from the
> cgroup people -- specifically if they're OK with the filedesc juggling
> thing, because I know the sysfs people objected to such tricks.
> 

Long long ago, a feature that used this trick was accepted, and that's
cgroup taskstat.

You get an fd of a cgroup directory and send it to the kernel via netlink,
and then you'll receive some statistics, such as how many tasks are
running/interrupted in that cgroup.

> Also, it might make sense to add a CONFIG_PERF_CGROUP, even if you want
> it automagically set if CONFIG_PERF && CONFIG_CGROUP, its easier to find
> all related code if its under a single CONFIG_var.
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/