Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <20220709000439.243271-1-yosryahmed@google.com>
 <20220709000439.243271-5-yosryahmed@google.com> <370cb480-a427-4d93-37d9-3c6acd73b967@fb.com>
 <a6d048b8-d017-ea7e-36f0-1c4f88fc4399@fb.com> <CA+khW7gmVmXMg4YP4fxTtgqNyAr4mQqnXbP=z0nUeQ8=hfGC3g@mail.gmail.com>
 <2a26b45d-6fab-b2a2-786e-5cb4572219ea@fb.com>
In-Reply-To: <2a26b45d-6fab-b2a2-786e-5cb4572219ea@fb.com>
From:   Hao Luo <haoluo@google.com>
Date:   Wed, 20 Jul 2022 17:40:53 -0700
Message-ID: <CA+khW7jp+0AadVagqCcV8ELNRphP47vJ6=jGyuMJGnTtYynF+Q@mail.gmail.com>
Subject: Re: [PATCH bpf-next v3 4/8] bpf: Introduce cgroup iter
To:     Yonghong Song <yhs@fb.com>
Cc:     Yosry Ahmed <yosryahmed@google.com>,
        Alexei Starovoitov <ast@kernel.org>,
        Daniel Borkmann <daniel@iogearbox.net>,
        Andrii Nakryiko <andrii@kernel.org>,
        Martin KaFai Lau <kafai@fb.com>,
        Song Liu <songliubraving@fb.com>, Tejun Heo <tj@kernel.org>,
        Zefan Li <lizefan.x@bytedance.com>,
        Johannes Weiner <hannes@cmpxchg.org>,
        Shuah Khan <shuah@kernel.org>,
        Michal Hocko <mhocko@kernel.org>,
        KP Singh <kpsingh@kernel.org>,
        Benjamin Tissoires <benjamin.tissoires@redhat.com>,
        John Fastabend <john.fastabend@gmail.com>,
        =?UTF-8?Q?Michal_Koutn=C3=BD?= <mkoutny@suse.com>,
        Roman Gushchin <roman.gushchin@linux.dev>,
        David Rientjes <rientjes@google.com>,
        Stanislav Fomichev <sdf@google.com>,
        Greg Thelen <gthelen@google.com>,
        Shakeel Butt <shakeelb@google.com>,
        linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
        bpf@vger.kernel.org, cgroups@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Mon, Jul 11, 2022 at 8:45 PM Yonghong Song <yhs@fb.com> wrote:
>
> On 7/11/22 5:42 PM, Hao Luo wrote:
[...]
> >>>> +
> >>>> +static void *cgroup_iter_seq_start(struct seq_file *seq, loff_t *pos)
> >>>> +{
> >>>> +    struct cgroup_iter_priv *p = seq->private;
> >>>> +
> >>>> +    mutex_lock(&cgroup_mutex);
> >>>> +
> >>>> +    /* support only one session */
> >>>> +    if (*pos > 0)
> >>>> +        return NULL;
> >>>
> >>> This might be okay. But want to check what is
> >>> the practical upper limit for cgroups in a system
> >>> and whether we may miss some cgroups. If this
> >>> happens, it will be a surprise to the user.
> >>>
> >
> > Ok. What's the max number of items supported in a single session?
>
> The max number of items (cgroups) in a single session is determined
> by kernel_buffer_size which equals to 8 * PAGE_SIZE. So it really
> depends on how much data bpf program intends to send to user space.
> If each bpf program run intends to send 64B to user space, e.g., for
> cpu, memory, cpu pressure, mem pressure, io pressure, read rate, write
> rate, read/write rate. Then each session can support 512 cgroups.
>

Hi Yonghong,

Sorry about the late reply. It's possible that the number of cgroup
can be large, 1000+, in our production environment. But that may not
be common. Would it be good to leave handling large number of cgroups
as follow up for this patch? If it turns out to be a problem, to
alleviate it, we could:

1. tell users to write program to skip a certain uninteresting cgroups.
2. support requesting large kernel_buffer_size for bpf_iter, maybe as
a new bpf_iter flag.

Hao

> >
[...]
> >>> [...]