On 5/20/22 2:49 PM, Hao Luo wrote:
Hi Tejun and Yonghong,
On Fri, May 20, 2022 at 12:42 PM Hao Luo <haoluo@xxxxxxxxxx> wrote:
Hi Tejun and Yonghong,
On Fri, May 20, 2022 at 9:45 AM Tejun Heo <tj@xxxxxxxxxx> wrote:
On Fri, May 20, 2022 at 09:29:43AM -0700, Yonghong Song wrote:
<various stats interested by the user>
This way, user space can easily construct the cgroup hierarchy stat like
cpu mem cpu pressure mem pressure ...
cgroup1 ...
child1 ...
grandchild1 ...
child2 ...
cgroup 2 ...
child 3 ...
... ...
the bpf iterator can have additional parameter like
cgroup_id = ... to only call bpf program once with that
cgroup_id if specified.
Yep, this should work. We just need to make the cgroup_id parameter
optional. If it is specified when creating bpf_iter_link, we print for
that cgroup only. If it is not specified, we iterate over all cgroups.
If I understand correctly, sounds doable.
Yonghong, I realized that seek() which Tejun has been calling out, can
be used to specify the target cgroup, rather than adding a new
parameter. Maybe, we can pass cgroup_id to seek() on cgroup bpf_iter,
which will instruct read() to return the corresponding cgroup's stats.
On the other hand, reading without calling seek() beforehand will
return all the cgroups.
Currently, seek is not supported for bpf_iter.
const struct file_operations bpf_iter_fops = {
.open = iter_open,
.llseek = no_llseek,
.read = bpf_seq_read,
.release = iter_release,
};
But if seek() works, I don't mind to remove this restriction.
But not sure what to seek. Do you mean to provide a cgroup_fd/cgroup_id
as the seek() syscall parameter? This may work.
But considering we have parameterized example (map_fd) and
in the future, we may have other parameterized bpf_iter
(e.g., for one task). Maybe parameter-based approach is better.
WDYT?
