""#Rust in the [#Linux] #kernel is no longer experimental — it is now a core part of the kernel and is here to stay. So the "experimental" tag will be coming off […]""

https://lwn.net/Articles/1049831/

#Rustlang #LinuxKernel

The end of the kernel Rust experiment

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

[$] An open seat on the TAB

As has been recently announced, nominations are open for the 2025 Linux Foundation Technical Advisory Board (TAB) elections. I am one of the TAB members whose term is coming to an [...]

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

A number of DAMON changes for Linux 6.19-rc1 has merged into the mainline as a part of MM subsystem pull request [1]. I again recommend people to read Andrew's great summary of the important changes on MM subsystem.

Among the DAMON changes, below four specially come to me. I hope the first change to help my ex-colleagues, and appreciate to Quanmin and Bijan for their continued DAMON works. Fourth one is only for celebrating my Camino challenge completion;)

1. Per-memcg per-node memory usage based DAMOS auto-tuning [2]. This allows cgroup-level NUMA memory management, such as hot pages promotion, cold pages demotion and reclaim. This was developed as a collaboration with my now-ex-colleagues at Meta.

2. Address alignment fix for DAMON modules [3]. This was developed as a followup fix of ARM32 LAPE support, by Quanmin from Huawei.

3. Pin-point targets removal [4]. This was developed as a collaboration [5] with Bijan, as a followup of his vaddr-based DAMOS-migration to multi-destination nodes.

4. Kunit tests for online parameters commit [6]. I started working on this on the Camino de Santiago[7]. It has delayed much longer than I expected, but I finally made it.

[1] https://lore.kernel.org/20251203212918.82f1c9d3947940aeae263878@linux-foundation.org
[2] https://lore.kernel.org/20251017212706.183502-1-sj@kernel.org
[3] https://lore.kernel.org/20251020130125.2875164-1-yanquanmin1@huawei.com
[4] https://lore.kernel.org/20251023012535.69625-1-sj@kernel.org
[5] https://github.com/damonitor/damo/issues/36
[6] https://lore.kernel.org/20251111184415.141757-1-sj@kernel.org
[7] https://social.kernel.org/notice/AyFZuW4Infc0st1NjM

#linux #kernel #damon #pullrequest #6.19-rc1

I will be in Tokyo next week. I will have four sessions on OSSummit and LPC. I also reserved the full week for potential in-person and/or virtual DAMON beer/coffee/tea chats [1]. Even if you don't have a topic for DAMON, if you don't mind shaking my hand, please feel free to reach out to me and say hello :)

[1] https://lore.kernel.org/20251205195509.76051-1-sj@kernel.org

#linux #kernel #damon #ossummit #lpc #linux_plumbers

The last 5.4.y kernel release has now happened: https://lore.kernel.org/all/2025120319-blip-grime-93e8@gregkh/

Please don't use this branch anymore, it's really old, and pretty obsolete, and has over 1500 unfixed CVEs in it:
https://lore.kernel.org/all/2025120358-skating-outage-7c61@gregkh/

And if you are stuck with that kernel version for some reason, go ask your vendor to fix those 1500+ CVEs, otherwise you are paying for support that doesn't actually do anything for you...

#Linux 6.18.y is now officially a longterm kernel series, as can be seen here:

https://www.kernel.org/category/releases.html

Projected EOL is Dec, 2027 (two years from now) – just like the 6.1.y series. All the other series as of now are scheduled for EOL in about one year from now – and 5.4.y just was EOLed, as planned (see https://social.kernel.org/objects/da258e20-22b9-4805-a9e5-5a506eb2bf91 and https://git.kernel.org/pub/scm/docs/kernel/website.git/commit/?id=0f52d79a5053091c95a269ff6fddbece27ea1d64 ).

Note, the kernel.org front page for the next ~two months (e.g. until 6.19 is out) will keep listing 6.18.y as latest stable series, as it might break peoples scripts to call it longterm there:

https://git.kernel.org/pub/scm/docs/kernel/website.git/commit/?id=b9ea3472ee1d973f4c27d075c7e4445afa7ade89

Heya, Heya!

Before the presents land under the Christmas tree, we’re super happy and honored to reveal the name of our godfather for the 2026 edition: @corbet.

Huge thanks to him for giving us a bit of his time — we know how precious it is.

I was unable to take time on DAMON cpus/write-only monitoring extension project nowadays, while I privately receiving more interests and test results. Hence trying to take more time on it, and shared a rough plan for clarifying expected timelines: https://lore.kernel.org/20251128193947.80866-1-sj@kernel.org

The plan is also available on the blog: https://damonitor.github.io/posts/damon_cpus_write_monitoring_rfc_v3_plan/

#linux #kernel #damon #cpus-only #write-only #development_plan

@vbabka Yes, I remember that. Nevertheless I was unable to "confidently" say it, since someone who has no good way to check the fact might think I'm lying. That's why I'm happy with this great integration work :D. Anyway, appreciate all people who made this availableSUSE, including you!

@vbabka Glad to be able to confidently and proudly say CONFIG_DAMON is enabled on the one of best Linux distros, OpenSUSE https://oracle.github.io/kconfigs/?config=UTS_RELEASE&config=DAMON

#linux #kernel #damon #opensuse #oracle_kconfigs

RE: https://mastodon.social/@vbabka/115582339822470165

> this gives me a motivation for unifying the capacity and bandwidth expansion solutions. I may share a thought soon on the mailing list.

Just posted a rough and early idea about how to provide a holistic tiered memory management for both capacity (or, latency) and bandwidth: https://lore.kernel.org/all/20251114014255.72884-1-sj@kernel.org/

FYI, I got the idea from a chat with a dynamic interleaving developer at Micron, as I also noted on the mail, and HMSDK talk gave me more motivation to develop it.

#linux #kernel #damon #tpp #bandwidth

RE: https://social.kernel.org/objects/75d16f79-f7b5-40f5-8c41-14ec3274fac1

SK Hynix HMSDK presentation video at OSSummit Korea is now available: https://sched.co/2913n

As a part of the talk, HMSDK's CXL memory capacity expansion, which utilizes DAMON internally, is also introduced. It provides detailed explanation of design, their test setup, results, and even a multi-threads based tuning tip. Especially the evaluation using an LLM workload is impressive to me.

Also, this gives me a motivation for unifying the capacity and bandwidth expansion solutions. I may share a thought soon on the mailing list.

#linux #kernel #damon #hmsdk #ossummit_korea

Japan visa applications need to be in by 17 November at the latest: https://lpc.events/blog/current/index.php/2025/10/29/japan-visas-need-a-longer-processing-time/

Abstracts of my LPC sessions are available now.

- "Page-level and Fleet-wide Data Access Monitoring for Meta", Refereed tack, Friday afternoon: https://lpc.events/event/19/contributions/2075/
- "Actionable Data Access Monitoring Output Data and Format", Linux System Monitoring and Observability MC, Thursday morning: https://lpc.events/event/19/contributions/2059/
- "DAMON-based Pages Migration for {C,G,X}PU [un]attached NUMA nodes", Device and Specific Purpose Memory MC, Thursday morning: https://lpc.events/event/19/contributions/2066/

#linuxplumbers #linux #kernel #damon

RE: https://social.kernel.org/objects/7f6edd64-5fbf-4a5d-b192-d00894198ca0

And today I started a new position at the kernel team of crusoe.ai.

TWIMC, the "Linus opposes Link: tags with links to the patch submission" is saga over, as Linus wrote:

""[…] I do think that at least if people use the different domain, I won't complain.

I'm still not convinced it's a great idea, but at least it means that the "this is the source of the commit" is clearly separate from the "this is actual background". […]""

https://lore.kernel.org/all/CAHk-%3Dwj5MATvT-FR8qNpXuuBGiJdjY1kRfhtzuyBSpTKR%2B%3DVtw@mail.gmail.com/

#Linux #kernel #LinuxKernel

Today was my last day at Meta. It was great to be connected and work with the awesome and nice people. I believe nothing is really being ended though, since we will keep being connected and work together on upstream open source communities.

@gregkh Inspired by the results, I bought a ~$320 mini PC from Aamzon and ran kcbench.

```
Processor: AMD Ryzen 7 6800H with Radeon Graphics [16 threads]
Cpufreq; Memory: powersave [amd-pstate-epp]; 27841 MiB
Linux running: 6.12.48+deb13-amd64 [x86_64]
Compiler: gcc (Debian 14.2.0-19) 14.2.0
Linux compiled: 6.17.0 [.../.cache/kcbench/linux-6.17]
Config; Environment: defconfig; CCACHE_DISABLE="1"
Build command: make vmlinux
Filling caches: This might take a while... Done
Run 1 (-j 16): 161.38 seconds / 22.31 kernels/hour [P:1440%, 134 maj. pagefaults]
Run 2 (-j 16): 162.53 seconds / 22.15 kernels/hour [P:1441%, 140 maj. pagefaults]
Run 3 (-j 19): 172.87 seconds / 20.82 kernels/hour [P:1366%, 266 maj. pagefaults]
Run 4 (-j 19): 164.76 seconds / 21.85 kernels/hour [P:1446%, 258 maj. pagefaults]
Run 5 (-j 8): 190.83 seconds / 18.86 kernels/hour [P:742%, 49 maj. pagefaults]
Run 6 (-j 8): 190.21 seconds / 18.93 kernels/hour [P:743%, 55 maj. pagefaults]
Run 7 (-j 11): 178.62 seconds / 20.15 kernels/hour [P:1011%, 96 maj. pagefaults]
Run 8 (-j 11): 185.62 seconds / 19.39 kernels/hour [P:975%, 126 maj. pagefaults]
```

Seems not a bad option for a hobbyist kernel hacker! Thanks @kernellogger for making kcbench!

And I'd like to appreciate @linuxfoundation for supporting the trip for Kangrejos. It was hugely helpful!

#kangrejos #linuxfoundation

RE: https://social.kernel.org/objects/f9ebce6d-3948-497b-834a-0bf1758fc07a