According to LWN kernel source DB, the number of my Linux mainline commits exceeded 1,000 with 6.19-rc1. It feels like a moment to me.

Most commits were made for DAMON, but the 1,000-th commit was for zswap ;)

$ git log --oneline --author "SeongJae" | grep damon | wc -l           
872
$ nr=0; for c in $(git log --pretty=%h --reverse --author "SeongJae"); do nr=$((│[43] [PATCH v3] mm/damon/sysfs-schemes: Remove outdated TODO in target_nid_store() (Swaraj               
nr + 1)); if [ "$nr" -eq 1000 ]; then git log "$c" -1 --pretty="%h %s"; fi; done                                                                 
0fdaa13ee93a Docs/admin-guide/mm/zswap: s/red-black tree/xarray/

#linux #kernel #damon #zswap

At the 2025 #Linux #Kernel Maintainers Summit this week the "rust for Linux" experiment has just been deemed concluded (https://lwn.net/SubscriberLink/1050174/6b6d55c90ce1100f/ ).

Rust for Linux maintainer Miguel Ojeda now submitted a patch to follow up on that and remove the "The Rust experiment" section from the #Linux #kernel's docs, as "Rust is here to stay":

conclude the Rust experiment – https://lore.kernel.org/lkml/20251213000042.23072-1-ojeda@kernel.org/

He writes:

""The Rust support was merged in v6.1 into mainline in order to help determine whether Rust as a language was suitable for the kernel, i.e. worth the tradeoffs, technically, procedurally and socially.

At the 2025 Linux Kernel Maintainers Summit, the experiment has just been deemed concluded.

Thus remove the section -- it was not fully true already anyway, since there are already uses of Rust in production out there, some well-known Linux distributions enable it and it is already in millions of devices via Android.

Obviously, this does not mean that everything works for every #kernel configuration, architecture, toolchain etc., […]

But the experiment is done, i.e. Rust is here to stay.

I hope this signals commitment from the kernel to companies and other entities to invest more into it, e.g. into giving time to their kernel developers to train themselves in Rust.

[…]""

#LinuxKernel #Rustlang

""#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 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

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.

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

And my Kernel Recipes talk is now available: https://youtu.be/qYPCL1KGdQA

A big "Thank you!" to everyone involved!