Message-Id: <20241002064252.41999-1-wentaoz5@illinois.edu>
Date: Wed,  2 Oct 2024 01:42:52 -0500
From: Wentao Zhang <wentaoz5@...inois.edu>
To: nathan@...nel.org
Cc: Matt.Kelly2@...ing.com,
	akpm@...ux-foundation.org,
	andrew.j.oppelt@...ing.com,
	anton.ivanov@...bridgegreys.com,
	ardb@...nel.org,
	arnd@...db.de,
	bhelgaas@...gle.com,
	bp@...en8.de,
	chuck.wolber@...ing.com,
	dave.hansen@...ux.intel.com,
	dvyukov@...gle.com,
	hpa@...or.com,
	jinghao7@...inois.edu,
	johannes@...solutions.net,
	jpoimboe@...nel.org,
	justinstitt@...gle.com,
	kees@...nel.org,
	kent.overstreet@...ux.dev,
	linux-arch@...r.kernel.org,
	linux-efi@...r.kernel.org,
	linux-kbuild@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	linux-trace-kernel@...r.kernel.org,
	linux-um@...ts.infradead.org,
	llvm@...ts.linux.dev,
	luto@...nel.org,
	marinov@...inois.edu,
	masahiroy@...nel.org,
	maskray@...gle.com,
	mathieu.desnoyers@...icios.com,
	matthew.l.weber3@...ing.com,
	mhiramat@...nel.org,
	mingo@...hat.com,
	morbo@...gle.com,
	ndesaulniers@...gle.com,
	oberpar@...ux.ibm.com,
	paulmck@...nel.org,
	peterz@...radead.org,
	richard@....at,
	rostedt@...dmis.org,
	samitolvanen@...gle.com,
	samuel.sarkisian@...ing.com,
	steven.h.vanderleest@...ing.com,
	tglx@...utronix.de,
	tingxur@...inois.edu,
	tyxu@...inois.edu,
	wentaoz5@...inois.edu,
	x86@...nel.org
Subject: Re: [PATCH v2 0/4] Enable measuring the kernel's Source-based Code Coverage and MC/DC with Clang

Hi Nathan,

Thanks for all the comments!

On 2024-10-01 23:53, Nathan Chancellor wrote:
> Hi Wentao,
>
> I took this series for a spin on next-20241001 with LLVM 19.1.0 using a
> distribution configuration tailored for a local development VM using
> QEMU. You'll notice on the rebase for 6.12-rc1 but there is a small
> conflict in kernel/Makefile due to commit 0e8b67982b48 ("mm: move
> kernel/numa.c to mm/").
>
> I initially did the build on one of my test machines which has 16
> threads with 32GB of RAM and ld.lld got killed while linking vmlinux.o.
> Is your comment in the MC/DC patch "more memory is consumed if larger
> decisions are getting counted" relevant here or is that talking about
> runtime memory on the target device? I assume the latter but I figured I

Yes the build process (linking particularly) is quite memory-intensive if
the whole kernel is instrumented with source-based code coverage, no matter
it's with or without MC/DC. What you've observed is expected. (Although the
quoted message was referring to runtime overhead)

On the last slide of [8] I had some earlier data regarding full-kernel
build- and run-time overhead. In our GitHub Actions builds [9], I have
been keeping track of "/usr/bin/time -v make ..." output and the results
can be found in step => "4. Build the kernel" => "Print kernel build
resource usage". You may want to check them.

I am not aware of neat ways of alleviating this overhead fundamentally so I
would love any advice on it. And perhaps now the more recommended way of
using the proposed feature is to instrument and measure the kernel on a
per-component basis.

[8] https://lpc.events/event/18/contributions/1895/attachments/1643/3462/LPC'24%20Source%20based%20(short).pdf
[9] https://github.com/xlab-uiuc/linux-mcdc/actions

> would make sure. If not, it might be worth a comment somewhere that this
> can also require some heftier build resources possibly? If that is not

Sure.

> expected, I am happy to help look into why it is happening.
>
> I was able to successfully build that same configuration and setup with
> my primary workstation, which is much beefier. Unfortunately, the
> resulting kernel did not boot with my usual VM testing setup. I will see
> if I can narrow down a particular configuration option that causes this
> tomorrow because I did a test with defconfig +
> CONFIG_LLVM_COV_PROFILE_ALL and it booted fine. Perhaps some other
> option that is not compatible with this? I'll follow up with more
> information as I have it.

Good to hear that you've run it and thanks for reporting the booting issue.
You may send me the config if appropriate and I'll also take a look.

>
> On the integration front, I think the -mm tree, run by Andrew Morton,
> would probably be the best place to land this with Acks from the -tip
> folks for the x86 bits? Once the issue above has been understood, I
> think you can send v3 with any of the comments I made addressed and a
> potential fix for the above issue if necessary directly to him, instead
> of just on cc, so that it gets his attention. Other maintainers are free
> to argue that it should go through their trees instead but I think it
> would be good to decide on that sooner rather than later so this
> patchset is not stuck in limbo.

Yeah -mm tree sounds good to me. Let me work on v3 while we address the
booting issue and wait for others' opinions if any.

Thanks,
Wentao

>
> Cheers,
> Nathan

Powered by blists - more mailing lists