Back in 2025, a group of dev decided to embark on a journey to change how Swap would be handled.
Swap has been seen as a sub-optimal subsystem, balancing years of "bypass" and quick fix.
At the Linux Storage, Filesystem, Memory Management BPF, they hash out possible designs with crazy looking maps.
They created a multi-phase plan to rewrite how swap would be handled.
2 structures used to govern swap:
swap_map: Responsible for the reference count and some other flags.Lets go through why these are sub-optimal:
Xarrays are a tree structure, so going through them takes some time $O(\log N)$.
If you though 64MB chunks are weird, point to you! 64MB doesn't fit within the 4KB page framework.
By that i mean that you need more than 1 Page to store the Xarray, resulting in reduced performance as your system tries to get the information needed to get a page from swap.
But wait, there more! These pages making the Xarray don't have to be continuous.
So no easy read-ahead improvement here and a lot of Miss in where querying the TLB (Translation Lookaside Buffer).
TLB is the buffer inside the CPU cache for where pages are in RAM, TLB misses are very slow compared to TLB hits.
If this is not enough, lets think about the possibility of multiple core needing to work with data that happens to be on the same 64MB chunk.
This structure has a lock so in any practical sense, you are stuck in single core when it comes to swap.
The swap_map is a static byte array, so its generated at the same time as the swap, containing one byte per swap slot to track reference counts.
So each slot have there reference count, if the reference count is over 63 references, it will create an extension swap_map array.
Now the swap_map is not alone in being a byte array for each slot in swap.
Per-device zeromaps, memory control group (memcg) swap ownership arrays, and static cluster management structures will all be generated along with it.
Lets go into the numbers, per slot (which should be 4KB per slot) in swap, 3 to 11 BYTES of memory might be used.
This is not dynamic, IT WILL BE USED WHETHER YOU USE IT OR NOT!!!
So in a 1TB swap, 3Byte per 4KB page gets us 768MB and for 11Byte it gives us 2816MB...
JUST FOR THE MAPS.
Apart from these 2 structures being less than optimal, swap has a bunch of structural issues.
An example would be SWP_SYNCHRONOUS_IO which allows subsystems to bypass the swap cache during page faults.
The subsystems were talking about here would be Zram, Zswap, fast NVMEs....
This would create the possibility for race conditions, making it even harder to update swap code without breaking something.
They went about it in 4 phase:
Lets look at replacing the swap cache lookup Xarray.
The first step is changing the size of a chunk (the proper name is a cluster) to 2MB.
This will align it with the size of a PMD (Page Middle Directory).
2MB of 4KB pages gives us 512 slots to manage,
1 x 8-byte pointer per slot means that swap table will fit within 1 x standard page (4KB) making it optimal.
It being an array also gives us another improvement, the slot pointer can now be retrieved in on single operation,
instead of having to go through a tree.
We transform the $O(\log N)$ of the Xarray into a $O(1)$ of a standard array.
This is accompanied by the struct swap_cluster_info which manages each of these 2MB arrays and consumes 48Bytes per 2MB cluster.
Why is struct swap_cluster_info important? It allows to dynamically allocate these array,
meaning that the swap_cluster_info->*table can be set to NULL eliminating the need to allocate more than the 48Bytes when unused.
This first phase was merged in 6.18 (Nov 2025)
Now that the new blazing-fast swap table is in place,
the little hacks needed by other subsystems to interface with swap are not needed anymore.
SWP_SYNCHRONOUS_IO was removed and all the subsystems using it were switched over.
Other structural cleanups were made but we are already in weeds enough, This was merged in 7.0 (April 2026)
The swap_map is the source of most of the static memory lost.
This phase essentially tries to delete most of it, and fold it under already existing structures.
For example, the reference count is now included into the swap table.
Lets look at the notes left in the code for better clarity: https://elixir.bootlin.com/linux/v7.2-rc7/source/mm/swap_table.h#L21
Here we have:
- The swap count is included within the highest bits.
- The lowest bit is looked at to confirm if it is a Shadow entry.
This removes the need for the swap_map. it's removal saves 256MB on a 1TB swap.
This landed in 7.1 last release (June 2026)
This phase simplified allocation even more which allowed some additional optimizations, but here the part i want to talk about is Zeromap.
Zeromap is the ability to set a flag that states that the underlying data is only 0s.
This prevents un-necessary writes and reads and significantly improves throughput.
If we look again at our swap_table, the Z is the flag for Zeromap.
lets look at the math of all this with the 1TB swap test.
Phase 3 removed 256MB
Phase 4 removed an additional 512MB
So yes, the cost for swap is 0Byte per slot.
OK, i'm being a bit more technical, it is technically 0.09375Bytes per slot as we have the:
48Bytes struct swap_cluster_info that gives us 512slots
48/512= 0.09375Bytes...
Hats off to the devs, this is incredible work from them.
Special thanks to Kairui Song, who did a lot of the weightlifting,
he was by no means alone but it would be fair to say that this wouldn't have happened without him.
It is a 2nd page reclamation algorithm in the kernel that was added in 6.1 (late 2022) by Yu Zhao.[36] [37]
This is the mechanism that chooses when to push something out of memory to make place for something else.
It is critical for performance that these choice be as optimal as possible.
It is also extremely hard to make the right choices as we are asking our system to guess if a page will be use in the near future.
-
Also, a quick clarification, today i will use the word folio instead of page when talking about these subsystem.
Reminder: pages are chunks of memory, 4kb on X86. The CPU manages memory in page size chunk.
Since Matthew Wilcox introduced folios in 5.16 (Jan 2022), Memory management has been revamped to mostly (if not only) use folios. [38]
This means that, even if most documentation will talk about pages, the underling code uses folio. which is why i'll use "folio" today!
It seeks to fix the weaknesses of the original LRU.
LRU stands for Least Recently Used which is how the choice is made.
LRU works by creating multiple sets of 2 list: Active and Inactive
When a folio is created or used, it is put at the top of the Active list.
When a folio is not touched for some time, it is transferred to the top of the Inactive list.
When the system requires memory (or if it just wants to free some space in ram), it can free the bottom of the Inactive list.
A set is created for file-backed folios and another for anonymous folios.
This allows to prioritize freeing file-backed folios as freeing anonymous folios requires to copy it into swap.
If Cgroups are used, a set is created for each cgroups.
The issue with this system is the lack of granularity.
We have 2 mode and as soon as we get Cgroups involved,
comparing which list we should use for freeing becomes more complicated and less optimal...
The way we go about solving this is by changing how we know a folio was used and adding lists.
The traditional LRU know a folio was touched (or not) by applying rmap(reverse-mapping) to a folio within a list.
What rmap allows to do is to get the Page Table Entries(PTEs) linked to a folio.
Remember the PTE is essentialy a pointer to physical memory with additional flag.
The _PAGE_ACCESSED bit on the PTE is checked and a decision can be made on what should be done with the memory.
Something to keep in mind is that rmap is especially costly when used against anonymous folios, which is usually over 90% of a server's memory.[37]
The Multi-Gen LRU on the other hand doesn't scan the folios directly, it walks over a process' Page Table, scanning the PTEs directly.
PTEs being continuous in memory makes this process very fast.
Now about that adding list part. Instead of using the Active/Inactive pair, Multi-Gen LRU will have 4 generations.[39]
Generations act in a similar way as the previous pair, if a PTE wasn't used within a set timeframe,
it is pushed to the older generation.
The Generation information is stored within 3 bits inside of the Folio flags, these are easy to access from the PTE.
The 4 generations allows for better granularity and also allow for some clever preferential treatment:
After going through all of that, we would think that Multi-Gen LRU is used everywhere. but it ain't.
Now don't get me wrong, it is compiled in most kernels just not enabled or set up correctly.
This is because, what was a great idea wasn't improved upon. After its release in late 2022, not much changed about it.
Zicheng Wang [42], who works for Honor an android phone maker,
decided to share his experience with the Multi-Gen LRU on android in advance of The Linux Storage, Filesystem, Memory Management BPF Summit 2026.
After the submit, it became clear that the subsystem needed some work, to get it to where it should be.
In reality, it is an issue to have 2 separate LRU. It makes the kernel more complex and reduces certainty on how to interact with an unknown kernel.
Fixing Multi-Gen LRU could help with that.
going back in time
In 7.0, a patch allowing the Batched checking of the young flag allowed for a 60% perf gain in a reclaim file-backed folios test with ARM64 CPUs [44]
In 7.2, a patch improving the reclaim loop and dirty writeback handling yielded 30% perf gain with MongoDB on and NVME drive.
it was also said that slower i/o devices like HDD or network would benefit up to 100%.[45]
All of this work also prepares for even more change that is needed in order to make Multi-Gen LRU the ultimate LRU, i'll make sure to keep you updated.
The thread started between Mauro Carvalho Chehab[12] [13] (the maintainer for MEDIA INPUT INFRASTRUCTURE (V4L/DVB)) and Roman Gushchin [14] (Creator and lead dev of https://sashiko.dev/ an AI patch reviewer that started 4 months ago.) about how Sashiko should be implemented for the Media subsystems.
This sparked a debate about the place of AI in the linux kernel.
An argument was made by Laurent Pinchart [15] (Prolific media driver maintainer) that the AI patch reviewer should be Opt-In as the
>..."most basic rule" that subscription to services that deliver e-mails should be opt-in...
This was shut down by Mauro who said that it is the right of the author to know what is happening to their patch. [17]
Roman also added that it would add more work for the maintainer as they would have to manually check if the author had access to the AI review and forward it in the case of a critical issue.[18]
It was followed by Laurent saying that the sending of the patches should follow the first 2 "Rules" for AI in FOSS by the Software Freedom Conservancy [19]
The Software Freedom Conservancy is one of the organisation that are created to open lawsuits against anyone that violates their copyright under a GPL license. They are oppositional to AI.
Roman answered:
>I think it makes the point of sashiko - helping maintainers - unachievable.
This is where Linus stepped in.
With that, the point of view of Linus was made clear.
Lets still peak to the rest of the arguments that were made starting with the
Jacopo Mondi (Embedded Linux engineer and media driver maintainer NO PIC) sees it as additional work for maintainers saying:
>Far-fetched review comments, very convincing word salads mixed with
valuable findings have often been escalated by authors to maintainers
to have them distil the good from the bad.
Jason Gunthorpe [22] (Engineer at NVIDIA and fellow Canadian (the most important qualifier)) argued that the existence of AI created more work, writing:
> Now I have to go and read every Sashiko
report to see if there is something important that normal review
missed. I have fix all the drive by 'this is already broken' stuff it
finds. We get way more patches than we did before. Now everything
has to be looked at more skeptically if came from some AI slop.
and concluded by saying:
> We aren't saving time, or creating less work. My hope is we are
creating better quality, higher security and less bugs.[23]
Ted Tso (EXT4 maintainer and one of the earliest contributor to the kernel) was fairly active in the thread. He argued that:
> One of the things that really excites me about Shashiko is that it
reduces my workload. Whereas the false positives from Syxbot and
oss-fuzz have caused me more work, not less, and has had significantly
more noise than Shahiko. [24]
He also reinforced the possible improvement to Sashiko saying:
>In the case of (reviews containing false positives) those are bugs, and we should work to try to
improve the kernel review prompts. Roman has recently checked in
changes to reduce false positives in the media subsystem, and I've
reported a bug for a false positive when reviewing an ext4
contribution..., which has since been fixed.[25]
Steven Rostedt (One of the Units behind Realtime Linux (his pic[26])) stated that:
> In my experience, the noise has been less than the signal. And the noise is
usually special cases that even a human would likely miss.
Linus also outlined in an answer to Laurent that he believes that Sashiko
is Superior to tools like the Zero day bot (which ensure that the code with compile/boot)
and checkpatch.pl (perl script which checks for trivial style violations) saying:
>You are correct. The AI generated reports are usually much superior
and more flexible.
>
>They aren't just syntax highlighters or reporting "this doesn't
build", they actually find real non-trivial problems.
>
>Now, I'm not saying that one replaces the other. The zero-day bot
finding things that don't even build or boot are great. That's a
pretty hard and clear signal.
>
>But the AI reports are often a lot better than checkpatch reports have been.
>
>Those checkpatch reports have gone through years of trying to massage
them into something that adds more value than pain - and I do think
we're there now, but it really required that effort on the part of
checkpatch maintainers.
>
>And that's exactly the kind of effort we need for Sashiko and friends.[27]
Laurent answer this last email stating that:
>I consider that, today, there's no ethical justification for the use of
generative AI in FOSS development. [28]
This prompted Linus to end the discussion:
>So this is where the discussion ends.
>
>As I mentioned, Linux has never been a social warrior project.
>
>If you don't have technical reasons, you don't have reasons.
>
>You can choose not to use AI, but that's your PERSONAL choice.
>
>It has absolutely no impact on anybody else, and you should not expect
it to have any.
>...(AND LATER STATED)...
>And yes, I feel very strongly about this, not because I feel strongly
about AI per se, but because we have a long history interacting with
the FSF.
>
>They have their "ethical" reasons too, and use them as a weapon, and
as a way to drive away sane people.
>
>It's why Linux is not GNU/Linux, and why we call things "open
source" instead of "Free Software".
>
>So keep your ethics where they belong - in your personal life. Don't
try to enforce your ethics on others.[29]
Now here i know there is going to be 2 kind reactions.
If you reaction is the 2nd, let me explain!
It is healthy (and way more useful) to address moral issues in the correct venue.
Some places are made for ethics and morals (Politics) and other places are not.
The kernel is not the correct venue for moral objection with AI to be resolve (which makes the objection a waste of your time.)
Now to make it crystal clear, lets make an example:
analogy with Canadian boycott of the US, it would be ridiculous for me to ask from a maintainer to communicate only using Non-US servers. The core reason why such a thing is ridiculous is because it isn't part of the scope of the Linux kernel to resolve or help with this.
The Linux kernel is a purely technological/technical endeavor. Everything that is being done by Linus is in pursuit of enhancing the kernel in a technical sense.
Now, i would be lying if i told you that the thread ended there.
An attempt to counter this idea was provided [9] by highlighting the CodingStyle change: Inclusive Terminology in 2020 [10] .
This show ignorance of why the change for Inclusive Terminology in the first place. it wasn't because of some social justice war against the term "Slave" but the simple fact that better (and more precise) words exist which improves efficiency (as written in [10] )[11]
And i know someone is writing in the comments as we speak, NO Complying with the sanctions on Russia is not optional or a ethical or moral statement.
There was also a bunch of conspiracy theories after but that's just boring...
If this all feels unintuitive, here is a tip for you:
Some things can only be made better when you act within realm of politics.
Linux is a kernel, it wont stop, or fix, or change anything about AI.
(If you believe AI to be an issue) Voting and making AI a relevant issue (in a political sense) is how you will attain your goal.
So stop trying to fight on the wrong battlefield. You are wasting your energy and making yourself less effective in your goal.
In a multi-core environment, the optimal placing of a task is crucial to ensure best performance.
In 2025, Peter Zijlstra came up with a new way to know where to put the next task.
His patch. This sparked interest from multiple devs which argued on how to get it done in an optimal manner.
The final version of the patch was mostly made by Tim Chen with the help of Chen Yu.
This feature is enabled using the CONFIG_SCHED_CACHE Kconfig option.
It also put in place some of the code that will be needed in order to allow future user-facing control of such preferences.
It was debated that it should be part of the current patch to have these controls but the decision was made to keep only the narrow patch.
Now lets get into why this really matter, performance gain.[2]
The benchmark shows that in scenarios where the CPU is flooded with requests, it does perform way better as the task that are spawned on the same LLC have an heighten chance of hitting already cached data.
The gains are massive in benchs like PostgreSQL DB with 800 clients. 40% Lower latencies and better throughput.
I would not be surprised if we would see more come out of this feature in the near future (;[3]
This release contains almost no feature for ARM64. Not on the architecture side, Nor on the KVM side.
This is the result of a massive flood of AI found bug and fixes that took the whole time of the devs.
Now, let me be clear, this is by no mean negative as the code we want is a code free of bugs. (Find a fuc_i_g way to say this). Tools like https://sashiko.dev/ are used to find the bugs.[7] [8]
Last release 7.1 ARM64 got the CRC64 NVMe algorithm with NEON Polynomial Multiply Long (PMULL) giving a 6x performance, well, it is now available to ARM32. This would require you to run your ARM64 CPU in ARM32 mode. [31]
The removal of old i486 code continues and is extending to i586 and i686 code,
X86 now requires the Time Stamp Counter (TSC)(it counts the number of CPU cycles since its last reset) which means that AMD K5 is not supported anymore.[32]
X86 also now requires CX8 (CMPXCHG8B)((Compare and Exchange 8 Bytes)).
This Removed the Boot option no387 and
also allowed for the removal of the math-emu/ library code as there is no need to emulate a Floating-Point Unit (FPU). [34]
While talking about removing things, lets go through other removed things:
And more!
X86 now has a centralized CPUID data model which will make it easier to get the CPUID information in a more standardize way as the information will be encoded differently depending on the CPU.[35]
TDX now supports live update of the TDX module code.
By design, the only way to change the TDX module code in a permanent way is to flash the Bios. This doesn't mean that the engineer behind TDX didn't offer another solution to update the code.[5] There exist 2 version of the TDX module code:
Along with the live update support comes the support of a TDX kernel launched using kexec from a TDX host.
In 6.18, kexec support was added to TDX. kexec allows for a new kernel to be launched from an already running kernel. This allow for kernel updates, without a reboot.
The only issue is that only non-TDX kernel could be started from kexec. This limitation was removed.
This was achieved by disabling TDX (TDH.SYS.DISABLE SEAMCALL), clearing the most-likely poisoned cacheline and re-initialize
TDX from scratch.[4]
The option HAVE_BUILDTIME_MCOUNT_SORT was set, to take advantage of the build time sorting.[30]
To understand this change we must understand how Ftrace works, Ftrace (Function Tracer) allows to
analyze kernel execution, debug latency issues, profile performance bottlenecks, and inspect call graphs in real time.
The way it achieves this mcount/__fentry__ instructions at the start of each functions in the kernel.
Now these instructions are not always enabled.
At initialization, the kernel through ftrace_init() will detect where these instructions are and replace them by NOP operation (a do nothing instruction).
At the same time, it will note their address in a list called the __mcount_loc.
NOW.
This list need to be sorted for Ftrace to work which is done at boot-time, but when all the conditions are met,
the list can be generated and sorted at build-time, which saves some time at boot!
Now has rust support.[69]
Its not all from Namjae Jeon, he also added compression support to ksmbd (the in kernel SMB server).[58]
Massive optimization to /proc/filesystems.
/proc/filesystems may be a file that you never though about, but it is used a lot.
Sed is one such tools, it uses libselinux through GNUlib.
SED uses GNUlib https://github.com/mirror/sed/tree/master
GNUlib | lib/selinux-at.h | #include https://github.com/coreutils/gnulib/blob/master/lib/selinux-at.h#L17
libSELinux | selinux.h | is_selinux_enabled() | https://github.com/SELinuxProject/selinux/blob/64c49eb31cdfa4336b1c71e09b13b8b08435cc59/libselinux/include/selinux/selinux.h#L14
Which end us triggering selinuxfs_exists() | https://github.com/SELinuxProject/selinux/blob/64c49eb31cdfa4336b1c71e09b13b8b08435cc59/libselinux/src/init.c#L63
Which calls fp = fopen("/proc/filesystems", "re");
This means that /proc/filesystems being sub-optimal will affect way more than just the interested user...
Now, this is one of the cases of "This was not touch since the first implementation" as fs/filesystems.c is not edited often.
Now the resulting string is cached using RCU, which allows mostly read item to be efficiently stored and updated.
This results in a 444% performance increase in a small tailor-made benchmark.[51]
We have a dev flexing over in the IOMAP subsystem,
IOMAP is the bridge between the FS and the storage. It was created as a replacement for buffer-heads
Now, it is not everyday that we find a 5% gain in throughput within anything FS related, but it is even better when it comes in the simple moving of 2 lines of code.
Lets get into the fix, so the part of the code we are looking at is iterating over extents, now if the extent is the last one in the set (or if it is a set of 1)
there is no need to do the housekeeping of zeroing iter->iomap and iter->srcmap because they won't be used after.
The fix pushes the zeroing to only happen if this isn't the final extent, preventing 160Byte from being zeroed giving us that 5% boost.
Probably one of the most important change to FileSystems this release would be
the new documentation about how to get your FileSystem in the kernel.
Now, i don't think that this documentation will solve everything,
it is probable a requirement to be insane in order to make a FileSystem but
it does clarify what to expect and do.
So if we run over it quickly, it says that:
It also states some requirements and expectations:
The submitting process is also outlined. They make it clear that each topic need to be its own patch and that any change to the VFS interface need to have a very good reason for it.
They also state that it is an obligation to maintain the FS even when merged and that it should be maintain according to the latest VFS implementation.
This comes because as soon as an FS goes unmaintained, it becomes the resposability of the VFS maintainer. This makes it very have for them to upgrade VFS as it requires them to upgrade FS code, that they might not have much knowledge in.
This new documentation should help with that.[56]
A new flag for the openat2() system call was added.
The OPENAT2_REGULAR flag will make the syscall return an "EFTYPE" error-code when trying to open a special file with it.
This should prevent dumb situation when you might download to eternity by checking /dev/urandom with your browser. [57]
More efficient Freeing of contiguous Order-0 Pages.
Order-0 pages are individual 1 page. they are named that way because the buddy allocates using:
2^(order) so if order=0 it gives you 1 page.
Last year, a patch (mm/vmalloc: request large order pages from buddy allocator[46]) allowed for bulk request of order-0 pages from the buddy allocator.
This patch also introduced regressions on the freeing of large groups of Order-0 pages.
This is now fixed as the new patch now allows us to scan over contiguous Order-0 pages to free them in bulk, giving us some massive performance gain. [47]
Hardware KASAN (The Kernel Address Sanitizer) will now skip tagging of the stacks and page tables.
KASAN is a dynamic memory error detector. It detects use-after-free and out-of-bound bugs.
The tags on stacks and the page tables were always unused so this patch was able to save 256 tag setting instruction
per 4 kB page from being executed at allocation and deallocation time. [48]
Slab will defer the creation of the freelist until after bulk allocation.
Slab is the memory allocator for small, smaller than a page, allocations.
It works by creating "Slabs" of memory and dividing them in multiple chunks.
The freelist is there to know what the next free item in a slab is.
But in cases where the whole slab will be allocated, there is no need to waste our time generating the freelist.
This specific issue can be seen with sheaves which will often use full slabs.
This optimization cut down by more than 50% the allocation time.[49]
...along with that...
There was also some optimization allowing to detach and reattach partial slabs in bulk which granted 2% ~ 5% perf gain.[50]
Added Support for the Realtek RTL8159. Now this little chip allows for one of the most cursed 10GB network card i have seen in a good while.
Yep, its USB-C and under 100$... Kind of crazy to think that we are there, if it wasn't from Realtek i would call it a scam XD [52] [53]
-AMDGPU HDMI 2.1 FRL support at long last and toward the ultimate goal of full HDMI 2.1 support in the upstream AMDGPU driver.
-Introducing the new AMDGPU DC power module.
-AMD on the audio co-processor side is preparing for "substantial design changes" with their next-gen audio IP.
NEW USB4STREAM allows the transfer of packets from one Linux to another using a USB4 connection. This should give a High throughput, low latency way to send data between 2 computera with USB4 (which uses the USB-C connector.). It can be used to send data or even webcam video, It will be interesting to see the graphical user interface made for it, as it would be very cool to start one of these transfers without the terminal.[59]
Bug fix where if a PCIe device was hot-plugged, it could be limited to the speed of a first gen PCIe device. This is now fixed allowing Hot-Plugged PCIe devices to renegociate their speed, as they should. This fix should be backported other versions of the kernel as the bug exists since 2023.[60]
Perf data was now hardened against corrupted and malicious _perf.data_ output.
Perf is a perfomance analysis tool.
Perf can be used by outputing the data into a file to be analysed later.
It turns out that there isn't much check when it comes to how sane the data is.
This was improved with the help of AI, using both Claude and Sashiko to root out some bugs and possible issues with bad data.[61]
Userspace Hard lockup with timers fixed.
If you had a loop that would set a timer to execute in the past (using the smallest, already past time, of 1ns),
the timer would call clockevents_program_min_delta() that would wait for the smallest possible time that the timer can actualy wait for min_delta_ns,
but the loop being faster than the timer (min_delta_ns) means the timer would never go to 0,[63]
preventing the timer from executing anything and starving the system of interrupts.
This was fixed by preventing the timer from being reset when clockevents_program_min_delta() is used.[62]
Support for Apple M3 (from 2023) . This support is just the start, as it only allows to boot into a serial console.
Again, this is possible because of the incredible work from Asahi Linux who reverse-engineer the hardware to make their patches.[1]
AMD ISP4 driver was added to the kernel. The Image Signal Processor is used in high-end laptops to manage the webcam. Some distros like Ubuntu were packaging the driver but it is now part of the mainline.
Intel Computer Vision Sensing Controller (CVS) was added as well. it manages CSI-2 link (webcam connections).
Both driver allow the use of the webcam through V4L2 (Video for Linux API Version 2)[6]
free_page() was switch with kmalloc() which offers betters scalability.: https://www.phoronix.com/review/cache-aware-scheduling-hedt
: https://www.phoronix.com/news/Intel-TDX-Linux-7.2-No-Reboot
: https://lore.kernel.org/lkml/ai_PGPYpLyFr2Vyb@willie-the-truck/
: https://lore.kernel.org/lkml/20260618152747.132796-1-pbonzini@redhat.com/
: https://lore.kernel.org/linux-media/20260715201301.GB1824265@killaraus.ideasonboard.com/
: https://github.com/torvalds/linux/blob/master/Documentation/process/coding-style.rst
: https://lore.kernel.org/linux-media/20260713094120.GD1127719@killaraus.ideasonboard.com/
: https://lore.kernel.org/linux-media/20260713220427.582b28bf@foz.lan/
: https://lore.kernel.org/linux-media/7ia4mrvtrxjl.fsf@castle.c.googlers.com/#t
: https://lore.kernel.org/linux-media/20260715005909.GF1656185@killaraus.ideasonboard.com/
: https://lore.kernel.org/linux-media/4928C919-7999-4E76-ADCB-F8643FED105B@linux.dev/#t
: https://lore.kernel.org/linux-media/20260715174153.GB3846105@ziepe.ca/
: https://lore.kernel.org/linux-media/alfBvhZkAelq5RVf@mit.edu/
: https://lore.kernel.org/linux-media/amD6YEiOp7KkSMzu@mit.edu/
: https://lore.kernel.org/linux-media/20260715185141.GJ1778116@killaraus.ideasonboard.com/
: https://www.phoronix.com/news/Linux-Kernel-TSC-Unconditional
: https://lwn.net/ml/linux-kernel/20210313075747.3781593-1-yuzhao%40google.com/
: https://elixir.bootlin.com/linux/v7.2-rc6/source/include/linux/mmzone.h#L470
: https://lwn.net/ml/all/cb0c0a0bfc7247cf85858eecf0db6eca%40honor.com/
: https://lore.kernel.org/lkml/20260428-mglru-reclaim-v7-0-02fabb92dc43@tencent.com/
: https://lore.kernel.org/all/66919a28-bc81-49c9-b68f-dd7c73395a0d@arm.com/
: https://lore.kernel.org/lkml/20260612-vfs-procfs-v72-15e0a3b7e3d2@brauner/
: https://github.com/torvalds/linux/blob/master/Documentation/filesystems/adding-new-filesystems.rst
: https://www.phoronix.com/news/Linux-7.2-VFS-OPENAT2-REGULAR
: https://lore.kernel.org/lkml/alpine.DEB.2.21.2512080331530.49654@angie.orcam.me.uk/