On Tue, Jan 17, 2017 at 02:03:03PM +0100, Michal Hocko wrote: > On Sun 15-01-17 20:19:01, Tejun Heo wrote: > [...] > > So, what's proposed is a proper part of bpf. In terms of > > implementation, cgroup helps by hosting the pointers but that doesn't > > necessarily affect the conceptual structure of it. Given that, I > > don't think it'd be a good idea to add anything to cgroup interface > > for this feature. Introspection is great to have but this should be > > introspectable together with other bpf programs using the same > > mechanism. That's where it belongs. > > If BPF only piggy backs on top of cgroup to iterate tasks shouldn't we > at least enforce that the cgroup has to be a leaf one and no further > children groups can be created once there is BPF program attached? Why (again) this stupid constraint? If you want to use cgroups for tagging (like perf does), _any_ parent cgroup will also tag you. So creating child cgroups, and placing tasks in it, should not be a problem, the BPF thing should apply to all of them. -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
