#Linux 6.4-rc2 is now available for public testing and Linus Torvalds says that "it's been a fairly calm week as people are only
starting to find any issues from the merge window, but it all looks
fine." https://lkml.org/lkml/2023/5/14/248
What’s the upside of updating Linux Kernel to 6.3.1 on Ubuntu 23.04?
So far, the only thing I noticed is that it messed up my nvidia display driver 🤷♂️ #linux#linuxkernel#ubuntu
Oh, CONFIG_XFS_DEBUG=y, which means: […] We randomly chose a near block allocation strategy to use to improve code coverage, not the optimal one for IO performance. Hence the CPU usage and allocation patterns that impact IO performance are simply not predictable or reproducable from run to run. So, yeah, trying to bisect […] will not be reliable....
Reminder: a #kernel where uname -r prints something like "5.15.0-71-generic" is a vendor kernel that is likely quite different from #Linux 5.15.71[1].
In case of problems with such a kernel you thus must report them to your vendor.
That's because almost all upstream #LinuxKernel developers don't care about problems in such kernels, as they might happen due to modifications the vendor applied.
[1] it in fact is likely based on a much later Linux 5.15.y release
As a result, we found a sub-optimal #kernel readahead behavior. […] The rest was as simple as using #madvise in our code to disable the readahead in table writers. […]```
<https://questdb.io/blog/investigating-linux-phantom-disk-reads/> #Linux #LinuxKernel
Hmmm, immutable #Linux distros are currently ignored by the "How to quickly build a trimmed #LinuxKernel" text I recently added to the #kernel's documentation[1].
Is that fine for now? Or should I add a sentence or two about those?
For @fedora#silverblue at al. it seems using "ostree admin unlock --hotfix" might be the best solution when say doing a bisection.
🥳 Linus merged[1] my text[2] on how to quickly build a trimmed #Linux#kernel!
🥴 Already got the first bug report. But well, things happen. And this makes it a perfect opportunity to ask you again:
Please look at the text or even play the instructions through: If you find more things that need fixing it's straight forward for me to do so, as I have to send a patch soon anyway.
[…] Linux tries to balance throughput, response times, and scheduling fairness […] it is necessary to fine-tune #kernel […]. Let us take a look at the 10 major points that must be considered when developing a Linux system with hard real-time constraints. For each point I also mention a common pitfall of developers new to real-time with Linux.
There comes a day in the life of every #Linux#kernel regression tracker where they run into a report about a regression[1] apparently directly caused by a change @torvalds insisted on[2].
~10 hours after #Linux#kernel 6.3 was tagged in git[1] it's now available as signed tarball on kernel.org, too.
For a short overview on what's new, checkout https://lwn.net/Articles/929851/; for a more detailed view, follow its links to the LWN merge-window summaries.
Known-broken commits either
(a) get a timely fix […]
or
(b) get reverted
Not this kind of "this is broken, has been known to be broken for a long time, people have bisected it, and we're just sitting here wondering what to do".
``` #LinuxKernel