@vegard @kernellogger my own experience is that after I add a new feature during the merge window, I'll get a bug report that was actually from an older change before the merge window. Why did this happen? Because the new feature started stressing code paths that were not stressed before and uncovered bugs that existed for a long time. Hence you may see more bug fixes for old bugs early in the rc releases.

@kernellogger Kent's interactions reminds me of another file system creator from long ago, whose name I will not mention.

@a3f yep. The biggest difference is the interface. It shows up as another instance in the tracefs file system that can be enabled or read pretty much like any other instance. You can even use `trace-cmd` to start it, read it and even extract it. Although it will need some tweaks for extraction.

With my new persistent memory mapped ring buffer, were I can retrieve the tracing buffer from the previous boot that crashed, I was able to debug a recent issue. To do this, I added code to allow trace_printk() to be directed to the persistent ring buffer, along with enabling the printk console trace event (writes all printk()s to the tracing ring buffer), I was able to get the perfect idea of what was happening that lead up to the crash!

https://lore.kernel.org/lkml/20240823013902.135036960@goodmis.org/

ANNOUNCE Just released:

trace-cmd v3.3 and libtracecmd 1.5.2

libtracefs v1.8.1

libtraceevent v1.8.3

A tribute to Daniel Bristot de Oliveira from Linux Plumbers. https://lpc.events/blog/current/index.php/2024/07/06/in-memory-of-daniel-bristot-de-oliveira/

Daniel Bristot de Oliveira passed away on Monday, June 24th at the age of 37. Another sad loss for the Linux kernel developer community, Daniel will be sorely missed.

In memory of Daniel: https://t.co/kQCQyTCo1a

Mourning Daniel Bristot de Oliveira

https://lwn.net/Articles/979912/ #LWN

https://lwn.net/Articles/979912/

@andree Actually, the issue is the opposite. What we have is a one size scheduler that fits everyone. But I think it’s more like all season tires. Where they suck in all seasons, but suck equally. The issue I found most frustrating with making changes to the scheduler, is that you may make a change that helps your specific workload, but will cause regressions in someone else’s workload, and your change much be reverted. Now you are stuck with either our of tree patches, or your workflow suffers.

I’m not a big fan of BPF, but I have been a long advocate for pluggable schedulers. My preference would have been true kernel modules, or config options (like file systems), as BPF programs are IMO harder to collaborate on.

"And you get a scheduler, and you get a scheduler, and you get a scheduler"

[ stolen from a colleague ]

Linus Torvalds: And for everybody else as a "It's happening" heads-up.

Linux Plumbers 2024 has accepted 9 Microconferences! But we had 26 submissions for 18 slots! What to do with that? Read about it here: https://lpc.events/blog/current/index.php/2024/05/03/awesome-amount-of-microconference-submissions/

@jann @vbabka @T_X @kees Note, the CONFIG_PSTORE_FTRACE just adds hooks into the ftrace infrastructure to have it write into the pstore. What I did is different. Here you give the ftrace infrastructure a block of memory (starting address and size), and it will map its ring buffer on top of that. There’s no hooks. All functionality of ftrace will write into the that range of memory.

Yes, if pstore can give me a block of memory, I’ll use it. Really, the code I wrote just lets you use any block of memory. How I get that block of memory is part 2 of his story. 😉

@vbabka @T_X there is a printk trace event that writes all the printk output to the tracing ring buffer. Enable that event, and you have that feature. 😁

Just posted a proof of concept that allows you to read a trace after a reboot, including a kernel crash!
https://lore.kernel.org/lkml/20240306015910.766510873@goodmis.org/

@kernellogger But what if that “crazy” operation is actually documented in a man page?

 mkdir /tmp/tracing
# cp -r /sys/kernel/tracing/events /tmp/tracing
# exit
$ trace-cmd sqlhist -t /tmp/tracing ...

https://trace-cmd.org/Documentation/trace-cmd/trace-cmd-sqlhist.1.html

Doing some testing against a change; I ran two traces. Recording the trace before applying the patch as trace-b.dat and then calling the trace file after applying the patch as trace-a.dat. Then doing an ls trace*.dat I have:

trace-a.dat
trace-b.dat

And it looks like trace-a.dat should come before trace-b.dat. I’m so confused! 😛

Looks like a lot of people are still without power in Portland. Linus gets a surprise vacation during the merge window 🫤