@kernellogger@fosstodon.org
@kernellogger@fosstodon.org avatar

kernellogger

@kernellogger@fosstodon.org

Mainly tooting about #Linux the #kernel and things related to the #LinuxKernel – e.g. #bootloader, #compiler, #git, #glibc, #mesa, #qemu, #xorg, #X11, #wayland, and other stuff in the 'plumbing' layer.

Opinions are my own.

Topic account. Other accounts of mine:

https://social.linux.pizza/@knurd42 (EN): #FLOSS, #Fedora as well as Life, the Universe and Everything
https://norden.social/@thleemhuis (DE): Das Leben, das Universum und der ganze Rest
https://social.tchncs.de/@thleemhuisfoss (DE): #FLOSS

searchable

This profile is from a federated server and may be incomplete. Browse more on the original instance.

kernellogger, to linux
@kernellogger@fosstodon.org avatar

How Allegro reduced latency outliers by 82% by switching to :

https://blog.allegro.tech/2024/03/kafka-performance-analysis.html

"'Using a combination of packet sniffing, , and async-profiler we managed to identify the root cause of slow produce requests in our Kafka cluster. We then tested a couple of solutions to the problem: data=writeback journaling mode, fast commits, and changing the file system to XFS.[…] With XFS, the number of produce requests exceeding 65ms (our SLO) was lowered by 82%.'"

kernellogger, (edited ) to linux
@kernellogger@fosstodon.org avatar

Getting closer and closer to the point where I'll start a git tree[1] with fixes and reverts for regressions in the latest stable series, as from here it seems quite a few of the known problems could quickly be solved by a revert or applying fixes already queued[2]/still under review[3].

[1] ideally in collaboration with the package maintainers from distros like @archlinux, @fedora, and @opensuse

[2] https://lore.kernel.org/all/a810561a-14f3-412e-9903-acaba7a36160@leemhuis.info/

[3] https://lore.kernel.org/all/ded3e7ae-6a7d-48b2-8acc-c125874ee09f@leemhuis.info/

kernellogger,
@kernellogger@fosstodon.org avatar

2/ In case anyone wonders "why not simply fix the problems in upstream ":

That would definitely be preferred! But in practise this often is anything but quick due to various reasons. Two of them:

  • Mainline developers are free to ignore stable and thus sometimes see no need to fix something quickly when the next mainline release is still weeks away.

  • The stable team only applies fixes that were mainlined and thus usually can not fix anything that occurs in mainline as well.

kernellogger,
@kernellogger@fosstodon.org avatar

@verdre

Yes, I'm sure that is not primarily a tooling problem, as the way bigger problem clearly is the workflow/motivation problem I mentioned ("Mainline developers […] see no need to fix something quickly"): different tooling alone would not make that go away (but of course with different tooling workflows also often get changed).

kernellogger,
@kernellogger@fosstodon.org avatar

@gromit @archlinux @fedora @opensuse

Not really, as mentioned in my reply-to-self: https://fosstodon.org/@kernellogger/112337080822568186

kernellogger,
@kernellogger@fosstodon.org avatar

@gromit

Thx.

And reg. that page: yup, but I guess there are always a few regressions I'm missing that @archlinux @fedora @opensuse kernel package maintainers are aware of; furthermore they are all in round about the same situation, so collaborating likely would make a lot of sense there.

kernellogger,
@kernellogger@fosstodon.org avatar

@gromit @archlinux [dropping two others]

One of the things I (and I guess some kernel developers as well) always wondered:

How many patches does Arch Linux apply to their default kernel (aka how close to vanilla is it)?

Fedora for example has a list of patches here: https://src.fedoraproject.org/rpms/kernel/blob/f40/f/Patchlist.changelog

Does arch linux have something similar (that ideally does not require one to clone some git tree to get the answer)?

kernellogger,
@kernellogger@fosstodon.org avatar

@archlinux

thx, @gromit and @oleksandr !

kernellogger, to random
@kernellogger@fosstodon.org avatar

9.0.0 is out:

https://www.qemu.org/2024/04/23/qemu-9-0-0/

https://wiki.qemu.org/ChangeLog/9.0

"'block: virtio-blk now supports multiqueue where different queues of a single disk can be processed by different I/O threads

migration: support for “mapped-ram” capability allowing for more efficient VM snapshots, improved support for zero-page detection, and checkpoint-restart support for VFIO

ARM: architectural feature support for ECV, NV, and NV2

ARM: board support for […] raspi4b (Raspberry Pi 4 Model B)"'

kernellogger, to linux
@kernellogger@fosstodon.org avatar

[PATCH RFC 0/7] block: Introduce CBD (CXL Block Device)

https://lore.kernel.org/all/20240422071606.52637-1-dongsheng.yang@easystack.cn/

"'As shared memory is supported in CXL3.0 spec, we can transfer data via CXL shared memory. CBD means CXL block device, it use CXL shared memory to transfer command and data to access block device in different host […]

[…] any shared memory can be used for cbd, but I did not find out a better name, maybe smxbd(shared memory transport block device)? I choose CBD as […]"'

kernellogger,
@kernellogger@fosstodon.org avatar

@hrw

Be careful who you tell this, I guess for some people that double meaning would be a reason to stick to the name. 😬

kees, to random
@kees@fosstodon.org avatar

Is anyone using an i386 Linux kernel, built with Clang, and configured with UBSAN? :P Something is going very wrong with the UBSAN handler calls. Anyone wanna help me debug this? https://github.com/KSPP/linux/issues/350

kernellogger,
@kernellogger@fosstodon.org avatar

@kees @ljs @vbabka

Clang? 32-bit kernel? That rang a bell in my head, as it reminded me of this:

https://lore.kernel.org/all/202403281553.79f5a16f-lkp@intel.com/

Might be totally unrelated, just thought I mention it in case it might not.

kernellogger, to linux
@kernellogger@fosstodon.org avatar

6.9-rc5 is out:

https://lore.kernel.org/lkml/CAHk-=wgfck-6-2YcD3Bzhjo0E0L0g2HGSZksB9pzRCah=Y4HBw@mail.gmail.com/

"'Another week, another -rc. Things look fairly normal, […]'"

major, to random
@major@social.lol avatar

If you have a newer Z13/Z16, there's a bug in the 6.8 kernel that prevents the touchpad from starting up:

https://bbs.archlinux.org/viewtopic.php?id=293971

kernellogger,
@kernellogger@fosstodon.org avatar

@major

Fix now mainlined: https://git.kernel.org/torvalds/c/ea36bf1827462e4a52365bf8e3f7d1712c5d9600 (but that was too late for the next 6.8.y release)

Side note: used the situation to point out a structural problem (aka "annoy a few people"): https://lore.kernel.org/all/a810561a-14f3-412e-9903-acaba7a36160@leemhuis.info/

Linus replied to my "what's your stance on regression fixes sitting in subsystem git trees for a week or longer before being mainlined" there:

"Annoying, […]"

kernellogger, to linux
@kernellogger@fosstodon.org avatar

CIQ Launches Support for Upstream [] kernels in

https://www.prweb.com/releases/ciq-launches-support-for-upstream-kernels-in-rocky-linux-uniting-stability-compatibility-security-and-performance-302119182.html

"'CIQ […] today launched fully supported, upstream stable kernels for Rocky Linux […]

Built on the upstream Linux kernel (i.e., mainline stable and long-term stable releases), these performance-optimized kernels ensure that Rocky Linux users benefit from the most recent innovations. […]'"

kernellogger, to linux
@kernellogger@fosstodon.org avatar

udev-hid-bpf: quickstart tooling to fix your HID [Human Interface Devices] devices with :

https://who-t.blogspot.com/2024/04/udev-hid-bpf-quickstart-tooling-to-fix.html

@whot writes:

"'[…] been working on and polishing a little tool called udev-hid-bpf [1]. This is the scaffolding required quickly and easily write, test and eventually fix your HID input devices (mouse, keyboard, etc.) via a BPF program instead of a full-blown custom kernel driver or a semi-full-blown patch.'"

[1] https://libevdev.pages.freedesktop.org/udev-hid-bpf/index.html

b0rk, to random
@b0rk@jvns.ca avatar

a git cheat sheet

kernellogger,
@kernellogger@fosstodon.org avatar

@b0rk maybe it's just me, but somehow I missed a short mention of "git diff" or a pointer to the "diff staged/unstaged changes" section in "know where you are" (or maybe in "prepare to commit"?), as that will show you what you are about to commit – which is usually what I really want to do to prevent doing something stupid. But as I said, maybe that's just me.

[Edit: or maybe move the "diff staged/unstaged changes" between "know where you are" and "prepare to commit"?]

kernellogger, to linux
@kernellogger@fosstodon.org avatar

The infra for a "blue screen of death" in the has landed in -next[1] and thus is slated for inclusion in 6.10:

https://lore.kernel.org/all/20240409163432.352518-1-jfalempe@redhat.com/

"'This introduces a new drm panic handler, which displays a message when a panic occurs. So when fbcon is disabled, you can still see a kernel panic.

[…]

It works with simpledrm, mgag200, ast, and imx.

[…]

Even if this is not yet useful, it will allows to work on more driver support, […]"'

[¹] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/log/?qt=grep&q=drm%2Fpanic

kernellogger,
@kernellogger@fosstodon.org avatar

@pid_eins

Who speaks there?

An employee of a well known company that has something like that for many years now or the maintainer of a software that later implemented something like that? ;-)

/me runs and hides

kernellogger, to linux
@kernellogger@fosstodon.org avatar

The new system call ()[1] after multiple revisions and various discussions[2] finally made it to -next and thus is slated to appear in 6.10:

https://lore.kernel.org/all/20240415163527.626541-1-jeffxu@chromium.org/T/#u

[1] "In a nutshell, mseal() protects the VMAs of a given virtual memory range against modifications, such as changes to their permission bits."

[2] https://lwn.net/Articles/948129/

kernellogger,
@kernellogger@fosstodon.org avatar

@jarkko

and ntsync: seems many people are really excited about it.

Would be kinda funny if lots of native Linux apps over time to start relying on a technique with "nt" in the name 😄

kernellogger, to linux
@kernellogger@fosstodon.org avatar

Reminder: if you want to link to some discussion on lists like , use the official archives at https://lore.kernel.org/

The service is more reliable than archives 3rd parties run[1]. And even in the unlikely case that lore is down, you have the msgid in the URL – which is all you need to find the message in other archives.

[1] like lkml.org, which appears to be broken currently

kernellogger, to linux
@kernellogger@fosstodon.org avatar

Now on : a discussion if usage of WARN*() should be discouraged in , because quite a few systems have panic_on_warn set (and then a warn leads to a panic):

https://lore.kernel.org/all/20240414170850.148122-1-elder@linaro.org/

gustavoars, to random
@gustavoars@fosstodon.org avatar

My looong journey to @everythingopen started this afternoon. I'm really excited about this trip (my first time visiting Australia). 🙏🏽 I cannot wait to meet/make new friends on the other side of the world. 🌏

Feel free to say hi if you see me around! 🙂🐧✌🏽

kernellogger,
@kernellogger@fosstodon.org avatar

@gustavoars @everythingopen

Would be worth a re-toot a lot more if the screenshot or the toot would mention what the talk is about 🙃

kernellogger,
@kernellogger@fosstodon.org avatar

@gustavoars @everythingopen

thx!

  • All
  • Subscribed
  • Moderated
  • Favorites
  • •
  • JUstTest
  • thenastyranch
  • DreamBathrooms
  • ethstaker
  • InstantRegret
  • Youngstown
  • magazineikmin
  • osvaldo12
  • slotface
  • khanakhh
  • rosin
  • kavyap
  • everett
  • tacticalgear
  • provamag3
  • ngwrru68w68
  • GTA5RPClips
  • cisconetworking
  • mdbf
  • cubers
  • Durango
  • anitta
  • modclub
  • normalnudes
  • tester
  • Leos
  • megavids
  • lostlight
  • All magazines
    •