From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-179.mta0.migadu.com (out-179.mta0.migadu.com [91.218.175.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4ABA130EF7B for ; Tue, 7 Jul 2026 01:50:24 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.179 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783389025; cv=none; b=pGX5/wVTzWOrixwA71mVxmWpkLSCXLfhE1jIQIVn+ZlbzS9BXHo/AfN1nEYAMQG4Nkp9q4txKYC7e6+h0VzNlHgLGVBIYU4vTX4HePSxU7gAAh6RJxu6wANCMJoRe6sTWJhsKXtQ5L5Arn6tWZ4dNpH5nfA/oPGBXMzNHtlzGQ0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783389025; c=relaxed/simple; bh=C9KKzrMhbHQ4j6vaR8/cSitMU7Oq2QiOexBUmdy+Mi8=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=R+PITl791VXwO1jZ3VMbPxt9VKVmhi5M1JaAFH+uqZb4v9rLVA6BEeOnlpBjOU0Y/dL7FOrzPCFMY1hHBp1qufdIXcRnkVneHWEkQWsXmipeYvIZ41tPtrI9GbkMcat5jFLKLW5IfRD84CtH6WFZQ3miB/tba4FW/kyCqHFyUpQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=iGuO03Qb; arc=none smtp.client-ip=91.218.175.179 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="iGuO03Qb" Date: Mon, 6 Jul 2026 18:50:05 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1783389012; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=pTk3bWiQbEnp9NY0pyiBv+XodrV//lC9BoLhtxJEGoA=; b=iGuO03QbteJKA9aIihTwgX5AqWkgRqrX05rDKfDWlAWxDk7BNPcW0y5ca39Xps5t56uFb/ 16s4rxVCluAQKhlh0zAY3smINquMtK0ZkTszFMX2OyuRCmfoPf5vVYOqLwrcLGYWDiEW8h Qjag8AlxR8nfinWL6s7frKd+vQzT4ls= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Shakeel Butt To: Eduard Zingerman Cc: Ziyang Men , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Kumar Kartikeya Dwivedi , bpf@vger.kernel.org, Martin KaFai Lau , Song Liu , Yonghong Song , Jiri Olsa , Emil Tsalapatis , Shuah Khan , Roman Gushchin , kernel-team@meta.com, linux-mm@kvack.org, cgroups@vger.kernel.org, linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 0/3] selftests/bpf: compare BPF and memory.stat memcg stat readers Message-ID: References: <20260704045617.487664-1-ziyang.meme@gmail.com> Precedence: bulk X-Mailing-List: bpf@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Migadu-Flow: FLOW_OUT On Mon, Jul 06, 2026 at 05:17:50PM -0700, Eduard Zingerman wrote: > On Fri, 2026-07-03 at 21:56 -0700, Ziyang Men wrote: > > [...] > > Hi Ziyang, > > I'm a bit hesitant adding 2.5K lines of code to the BPF selftests, > as this code would need to be (a) maintained, (b) run at each CI invocation. > Hence, the tests added need to be relevant for the BPF sub-system. > > Regarding the benchmarking part, as you state yourself: > > > In my testing (a 60-CPU VM) the BPF path is roughly an order of magnitude > > faster than the per-cgroup memory.stat parse for a whole-tree scan, mainly > > because it avoids the per-cgroup open/read and string parsing. > > With this, I think the benchmarking code can be dropped altogether. > > Next, the three memcg_stat_{reader,churn,churn_percpu}.c files share a > lot of utility code almost verbatim (e.g. tree definition/construction). > Such duplication should be avoided. > > Finally, from the BPF point of view the test exercises the following functionality: > - kfuncs: > - bpf_mem_cgroup_page_state > - bpf_mem_cgroup_vm_events > - bpf_put_mem_cgroup > - bpf_get_mem_cgroup > - main iterator logic. > > All kfuncs but bpf_get_mem_cgroup() are thin wrappers around mm/memcontrol.c code, > all kfuncs including the bpf_get_mem_cgroup() are already exercised in the selftests. > The iterator logic itself is covered by 8 sub-tests in the prog_tests/cgroup_iter.c. > Hence two questions: > - What do these new tests add in terms of tests coverage? > - Why do BPF selftests need to exercise the churn and churn_percpu scenarios? > > Shakeel, could you please comment as well? Hi Eduard, Thanks a lot for taking a look. The main motivation I had behind requesting Ziyang to send this series (beside making him learn the tooling and process of sending patches to lkml) was to have a reference implementation and performance comparison for BPF based cgroup/memcg stats collection. However you have correctly pointed out that selftests might not be the right place for such kind of code as selftests are more focused on functional tests and run by a lot of CIs while this is a performance benchmarking code. I am wondering if there is a place for this benchmarking code in kernel under tools folder but archiving it on lkml might be good enough and should be easily searchable. Anyways thanks again for your time. thanks, Shakeel