And today’s hack is: https://lore.kernel.org/all/20230306122529.44e8d566@gandalf.local.home/

PowerTop has had a copy of libtraceevent for over 10 years, with the assumption it would use the external library when ready. That library has been ready for a few years now, but I finally got around to porting PowerTop to it. https://github.com/fenrus75/powertop/pull/122

Running my tests costs me a bit in my electricity bill!

I guess I’m not the only one that hates this: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1028643#26

@ljs Debian (testing)

@monsieuricon Maybe one day when searching for realtime linux kernel the first link will not be the obsolete kernel.org wiki!

Anyone else hate upgrades that mess with your fonts?? For some reason, every so often, after an upgrade. My default fonts are all messed up. WTF!

Now I know why they say there's a "FOSDEM Flu" 🤧 At least I didn't get the "FOSDEM Covid"!

I'm excited about my first time at FOSDEM. Unfortunately, all the talks I'm interested in are on Sunday. At least that means I can use tomorrow to figure out my way around the conference.

Copied my ktest.pl config from my server (58 cores / 256G of RAM) to my laptop. I guess running make -j120 isn’t good for the poor thing 😢

Today marks the day I officially converted my internal C and bin directories over to git from subversion. I have a set of personal tools I use (or just to test how things work) that I’ve kept in subversion.

Why?

Because the central repository was perfect for it. I did not care about distributed environment. I would always commit back to the central authority.

Why did I change?

Well, I do modify the code from different machines here and there, and I finally hit a merge conflict that is pretty much impossible to solve with subversion. Which caused me a couple of hours to get it back to a working state as subversion makes it very difficult to resolve nasty conflicts.

Thank God for git svn as I needed to maintain the history as well.

Oh well, Goodbye subversion. It was fun while it lasted.

For my day off, I decided to implement passing a stack trace from start event to end event (to show the backtrace of the longest blocked areas).

@1ace I only reboot this machine via drop down menus which doesn't care about my `.bashrc` files.

@kernellogger no, it just assumes if you log in via the X windows console, and your session has the right to reboot the machine, so does your xterm windows.

I ssh into my dev boards as root and reboot via that session. The issue is when I think I'm ssh'd in and go to reboot, I don't always notice the prompt is different and I can type `reboot <enter>` dangerously fast.

I usually add this to my .bashrc file to all my work machines.

alias reboot='echo "Wrong window idiot!"'
alias halt='echo "Wrong window idiot!"'
alias shutdown='echo "Wrong window idiot!"'

But I just learned, that I never added it to my Google workstation 😛

The blog on the responses from the Linux Plumbers survey is now published. https://lpc.events/blog/2022/index.php/2023/01/06/lpc-2022-attendee-survey-summary/

@hergertme as for getting that information in the kernel. If there’s an elf section for it, it shouldn’t be too hard. We are already looking into it. The idea is to flag that the task has the sframe section available, and when perf wants a trace, it will set a callback of some kind, and when the task is about to go back to user space, the section will be mapped in and call the perf callback to with the user space stacktrace.

It doesn’t matter when the user space stacktrace happens inside the kernel, it’s not going to change.

@hergertme sframe is similar to ORC. I guess it we should take some time to do the benchmarks with and without frame pointers, on critical loads.

ORC has solved the issue for the kernel, but currently profiling user space without frame pointers is “interesting”.

@hergertme Is there a performance penalty with this?

And if sframe support becomes default (after it is accepted), then we could teach the kernel to do user space stack tracing without frame pointers.

@ljs @joel_linux RCU is simply broken down into three parts:

• grace periods
• quiescent states
• synchronization

A quiescent state is a time or action that guarantees all grace periods that were running at the time of the synchronization have finished (but you do not care about grace periods that started after synchronization).

If a link list protected by disabling preemption, then the grace period is when preemption is disabled, and the quiescent state is when all CPUs have scheduled. So you can remove an item from the link list (where all readers must have preemption disabled to read it), and then wait for all CPUs to schedule which guarantees nothing has access to the item, where you are now free to delete it without worrying that something is reading it.

That’s the simple case. There’s more complex cases, but it all comes down to the three parts above.