Oh wow, what a loss for RH! https://lore.kernel.org/linux-mm/20251103103659.379335-1-david@kernel.org/T/#u

On Thursday, I sent this RFC: https://lore.kernel.org/lkml/20251023-sheaves-for-all-v1-0-6ffa2c9941c0@suse.cz/
On Friday, there was the expected phoronix coverage. But also an unexpected one:
https://www.nytimes.com/2025/10/24/learning/word-of-the-day-sheaf.html

took another cringe pic yesterday btw

WHOA!!

A lot has happened in my personal life this week (nothing serious, don’t worry). Everything seems to be settled now thankfully.

I've found that often people ask advice and want a _certain kind of reply_.

Then I give my actual one and get ignored.

This is why I don't really bother replying to 'how do you get started in the kernel' type questions so much now :)

People want some dopamine hit 'inspirational' message that massages their ego.

And you can find ENDLESS fuckers on this site who will give you that, the type who wear fancy scarfs and never reply to anybody who is 'below' them.

But they're lying to you guys.

The truth is the truth.

I have the same experience when people ask about weight loss...

It's very much the case that holywood/internet versions of laudable qualities are in strict contrast to how they actually look.

Courage, persistence, resilience, strength are all extremely gritty, nasty, unpleasant things that often get you ostracised.

Much easier to kid yourself and live in some opium-fuelled dream of how the world is. But people don't seem to like to wake up to that :)

It is always sad to say goodbye to a long holiday :’(

I'm thinking of making sandwiches on my own, as buying two a day really adds up each month! I just need to be careful not to make them too big and end up gaining weight...

Linux 6.18 sched_ext Preps For Cgroup Sub-Scheduler Support

The sched_ext scheduler framework that allows creating kernel thread schedulers via BPF programs is ready with some updates for the Linux 6.18 kernel...
https://www.phoronix.com/news/Linux-6.18-sched-ext

Taking random photos alone on Saturday

This week I once again had a great time at @KernelRecipes ! Thanks a lot for inviting me, and for organizing such a nice conference! (and also for all the nice speaker and attendee gifts :)

Also glad we increased the SUSE presence from just me last year to 4 people this year! (which miraculously required only 2 more people to attend, who weren't there last year).
#kr2025

A big issue in the kernel are asymmetries between review resource and patch submission.

If you have 20 inexperienced kernel engineers all doing big difficult work and submitting large series that need TONS of review (and sometimes essentially development-via-review) and only a few reviewers, you have a problem.

What compounds this is that not all review is equal.

It seems most people will only really look at the surface, and rather happily give tags.

I think that technical skill is not enough for review [as I have said very often - soft skills are the actually core ones] - you have to be willing to say no, you have to be willing to consider the wider picture.

Finding people who have the right skills, are willing to handle the stress + thanklessness, & who have the time is not easy.

So the asymmetry I think is insoluble.

It'd be good if we could have stricter controls to throttle incoming series though.

Here’s a progress update on my diet! It’s been five weeks now.
- Five workout sessions per week (focusing on losing fat)
- Eating only 2 sandwiches per day (most of the time!)

Target weight is about 70-75kg... so still a long long way to go.

Prototype for type-based partitioning of Linux kernel slab caches: https://discourse.llvm.org/t/rfc-a-framework-for-allocator-partitioning-hints/87434/24?u=melver

Compiler seems to be doing a good-enough job of inferring allocated types per /proc/slabinfo. With the diagnostic -Rpass=alloc-token I can see about 965 allocation sites where it failed to infer the allocated type, but most of them are "bag of bytes", and only few with complex sizeof calculations like struct_size that are too opaque right now (but can be fixed).

Working on saving 8 or 16 bytes per slab object in certain slab caches that fall into special cases, most notably 0.7%-0.8% or 1.5%-1.6% (depending on the configuration) memory savings for the inode cache (ext4 and xfs).

When memory cgroup and memory allocation profiling are enabled (the former being very common in production and the latter less so), the kernel allocates two pointers per object: one for the memory cgroup to which it belongs, and another for the code location that requested the allocation.

In two special cases, this overhead can be eliminated by allocating slabobj_ext metadata from unused space within a slab page:
- Case 1. The "leftover" space after the last slab object is larger than the size of an array of slabobj_ext.
- Case 2. The per-object alignment padding is larger than sizeof(struct slabobj_ext).

Thanks to @vbabka who suggested an excellent general approach to cover Case 1 and 2 with a minimal performance impact on the memory cgroup charging code (more details in the cover letter)

For these two cases, one or two pointers can be saved per slab object. Examples include the ext4 inode cache (case 1) and the xfs inode cache (case 2). That results in approximately 0.7-0.8% (memcg) or 1.5-1.6% (memcg + mem profiling) of the total inode cache size.

https://lore.kernel.org/linux-mm/20250827113726.707801-1-harry.yoo@oracle.com/

I should have been a photographer ?!

I didn't really work on my legs much before, but ever since I started PT, my legs hurt with every move I make

On diet day 3

Uh I don't want to misread code

First day of PT, quite tired.
…now my trainer says only two sandwiches are allowed every day. Oh no!

For a while now, the kernel's configuration and build systems have been an area of concern for me. Almost nobody truly understands those complex subsystems, which were handled by a single maintainer.

That maintainer, Masahiro Yamada, has just stepped down after eight years on the job:

https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=8d6841d5cb20

Happily, Nathan Chancellor and Nicolas Schier have agreed to pick up the build system. The configuration system, instead, is now unmaintained. That ... seems less than optimal.

Thanks to Masahiro for doing this work all these years, and to Nathan and Nicolas for stepping up!