The Arch Linux team has announced a collaboration with Valve, working to support critical infrastructure projects like a build service and secure signing enclave for the Arch Linux distribution. Tom's Hardware reports: If you're familiar with Valve and Steam Deck, you may already know that the Deck uses SteamOS 3, which is built on top of Arch Linux. Thanks to the Arch Linux base and Valve's development of the Proton compatibility layer for playing Windows games on Linux, we now have a far improved Linux gaming scene, especially on Valve's Steam Deck and Deck OLED handhelds. While Valve's specific reasons for picking Arch Linux for Steam Deck remain unknown, it's pretty easy to guess why it was picked. Mainly, it's a particularly lightweight distribution maintained since March 2002, which lends itself well to gaming with minimal performance overhead. A more intensive Linux distribution may not have been the ideal base for SteamOS 3, which is targeted at handhelds like Steam Deck first.

As primary Arch Linux developer Levente Polyak discloses in the announcement post, "Valve is generously providing backing for two critical projects that will have a huge impact on our distribution: a build service infrastructure and a secure signing enclave. By supporting work on a freelance basis for these topics, Valve enables us to work on them without being limited solely by the free time of our volunteers." Polyak continues, "This opportunity allows us to address some of the biggest outstanding challenges we have been facing for a while. The collaboration will speed up the progress that would otherwise take much longer for us to achieve, and will ultimately unblock us from finally pursuing some of our planned endeavors [...] We believe this collaboration will greatly benefit Arch Linux, and are looking forward to share further development on the mailing list as work progresses."

Long-time Slashdot reader dmitrygr writes: Debian Linux booted on a 4-bit intel microprocessor from 1971 — the first microprocessor in the world — the 4004. It is not fast, but it is a real Linux kernel with a Debian rootfs on a real board whose only CPU is a real intel 4004 from the 1970s.
There's a detailed blog post about the experiment. (Its title? "Slowly booting full Linux on the intel 4004 for fun, art, and absolutely no profit.")

In the post dmitrygr describes testing speed optimizations with an emulator where "my initial goal was to get the boot time under a week..."

The Tor Project: Today the Tor Project, a global non-profit developing tools for online privacy and anonymity, and Tails, a portable operating system that uses Tor to protect users from digital surveillance, have joined forces and merged operations. Incorporating Tails into the Tor Project's structure allows for easier collaboration, better sustainability, reduced overhead, and expanded training and outreach programs to counter a larger number of digital threats. In short, coming together will strengthen both organizations' ability to protect people worldwide from surveillance and censorship.

Countering the threat of global mass surveillance and censorship to a free Internet, Tor and Tails provide essential tools to help people around the world stay safe online. By joining forces, these two privacy advocates will pool their resources to focus on what matters most: ensuring that activists, journalists, other at-risk and everyday users will have access to improved digital security tools.

In late 2023, Tails approached the Tor Project with the idea of merging operations. Tails had outgrown its existing structure. Rather than expanding Tails's operational capacity on their own and putting more stress on Tails workers, merging with the Tor Project, with its larger and established operational framework, offered a solution. By joining forces, the Tails team can now focus on their core mission of maintaining and improving Tails OS, exploring more and complementary use cases while benefiting from the larger organizational structure of The Tor Project.

This solution is a natural outcome of the Tor Project and Tails' shared history of collaboration and solidarity. 15 years ago, Tails' first release was announced on a Tor mailing list, Tor and Tails developers have been collaborating closely since 2015, and more recently Tails has been a sub-grantee of Tor. For Tails, it felt obvious that if they were to approach a bigger organization with the possibility of merging, it would be the Tor Project.

"Looks like there's a storm brewing, and it's not good news," writes ancient Slashdot reader jd. "Whether or not the bugs are classically security defects or not, this is extremely bad PR for the Linux and Open Source community. It's not clear from the article whether this affects other Open Source projects, such as FreeBSD." From a report: A critical unauthenticated Remote Code Execution (RCE) vulnerability has been discovered, impacting all GNU/Linux systems. As per agreements with developers, the flaw, which has existed for over a decade, will be fully disclosed in less than two weeks. Despite the severity of the issue, no Common Vulnerabilities and Exposures (CVE) identifiers have been assigned yet, although experts suggest there should be at least three to six. Leading Linux distributors such as Canonical and RedHat have confirmed the flaw's severity, rating it 9.9 out of 10. This indicates the potential for catastrophic damage if exploited. However, despite this acknowledgment, no working fix is still available. Developers remain embroiled in debates over whether some aspects of the vulnerability impact security.

The Rust vs C battle raging in Linux circles has left even Linus Torvalds scratching his head. "I'm not sure why Rust has been such a contentious area," the Linux creator mused at this week's Open Source Summit, likening the fervor to ancient text editor wars. "It reminds me of when I was young and people were arguing about vi versus Emacs."

The spat over integrating Rust into Linux has been brewing since 2022, with critics slamming it as an "insult" to decades of kernel work. One maintainer recently quit, fed up with the "nontechnical nonsense." Torvalds struck a surprisingly diplomatic tone. He praised how Rust has "livened up discussions" while admitting some arguments get "nasty." "C is, in the end, a very simple language," Torvalds said, explaining its appeal and pitfalls. "Because it's simple it's also very easy to make mistakes. And Rust is not." Torvalds remains upbeat about Rust's future in Linux, nonetheless. "Even if it were to become a failure -- and I don't think it will -- that's how you learn," he said.

ZDNet's Steven Vaughan-Nichols reports: After 20 years, Real-Time Linux (PREEMPT_RT) is finally -- finally -- in the mainline kernel. Linus Torvalds blessed the code while he was at Open Source Summit Europe. [...] The real-time Linux code is now baked into all Linux distros as of the forthcoming Linux 6.12 kernel. This means Linux will soon start appearing in more mission-critical devices and industrial hardware. But it took its sweet time getting here. An RTOS is a specialized operating system designed to handle time-critical tasks with precision and reliability. Unlike general-purpose operating systems like Windows or macOS, an RTOS is built to respond to events and process data within strict time constraints, often measured in milliseconds or microseconds. As Steven Rostedt, a prominent real-time Linux developer and Google engineer, put it, "Real-time is the fastest worst-case scenario." He means that the essential characteristic of an RTOS is its deterministic behavior. An RTOS guarantees that critical tasks will be completed within specified deadlines. [...]

So, why is Real-Time Linux only now completely blessed in the kernel? "We actually would not push something up unless we thought it was ready," Rostedt explained. "Almost everything was usually rewritten at least three times before it went into mainline because we had such a high bar for what would go in." In addition, the path to the mainline wasn't just about technical challenges. Politics and perception also played a role. "In the beginning, we couldn't even mention real-time," Rostedt recalled. "Everyone said, 'Oh, we don't care about real-time.'" Another problem was money. For many years funding for real-time Linux was erratic. In 2015, the Linux Foundation established the Real-Time Linux (RTL) collaborative project to coordinate efforts around mainlining PREEMPT_RT.

The final hurdle for full integration was reworking the kernel's print_k function, a critical debugging tool dating back to 1991. Torvalds was particularly protective of print_k --He wrote the original code and still uses it for debugging. However, print_k also puts a hard delay in a Linux program whenever it's called. That kind of slowdown is unacceptable in real-time systems. Rostedt explained: "Print_k has a thousand hacks to handle a thousand different situations. Whenever we modified print_k to do something, it would break one of these cases. The thing about print_k that's great about debugging is you can know exactly where you were when a process crashed. When I would be hammering the system really, really hard, and the latency was mostly around maybe 30 microseconds, and then suddenly it would jump to five milliseconds." That delay was the print_k message. After much work, many heated discussions, and several rejected proposals, a compromise was reached earlier this year. Torvalds is happy, the real-time Linux developers are happy, print_K users are happy, and, at long last, real-time Linux is real.

An anonymous reader quotes a report from ZDNet, written by Steven Vaughan-Nichols: In a candid keynote chat at the Linux Foundation's Open Source Summit Europe, Linux creator Linus Torvalds shared his thoughts on kernel development, the integration of Rust, and the future of open source. Dirk Hohndel, Verizon's Open Source Program Office head and Torvalds friend, moderated their conversation about the Linux ecosystem. Torvalds emphasized that kernel releases, like the recent 6.11 version, are intentionally not exciting. "For almost 15 years, we've had a very good regular cadence of releases," he explained. With releases every nine weeks, this regularity aims for timeliness and reliability rather than flashy new features. The Linux creator noted that while drivers still make up the bulk of changes, core kernel development continues to evolve. "I'm still surprised that we're doing very core development," Torvalds said, mentioning ongoing work in virtual file systems and memory management. [...]

Shifting back to another contentious subject -- maintainer burnout and succession planning -- Hohndel observed that "maintainers are aging. Strangely, some of us have, you know, not quite as much or the right hair color anymore." (Torvalds interjected that "gray is the right color.") Hohndel continued, "So the question that I always ask myself: Is it about time to talk about there being a mini-Linus?" Torvalds turned the question around. True, the Linux maintainers are getting older and people do burn out and go away. "But that's kind of normal. What is not normal is that people actually stay around for decades. That's the unusual thing, and I think that's a good sign." At the same time, Torvalds admitted, it can be intimidating for a younger developer to join the Linux kernel team "when you see all these people who have been around for decades, but at the same time, we have many new developers. Some of those new developers come in, and three years later, they are top maintainers."

Hohndel noted that "to be the king of Linux, the main maintainer, you have to have a lot of experience. And the backup right now is Greg KH (Greg Kroah-Hartman, maintainer of the stable Linux kernel), who is about the same age as we are and has even less hair." True, Torvalds responded, "But the thing is, Greg hasn't always been Greg. Before Greg, there's been Andrew {Morton) and Alan (Cox). After Greg, there will be Shannon and Steve. The real issue is you have to have a person or a group of people that the development community can trust, and part of trust is fundamentally about having been around for long enough that people know how you work, but long enough does not mean to be 30 years." Hohndel made one last comment: "What I'm trying to say is, you've been doing this for 33 years. I don't want to be morbid, but I think in 33 years, you may no longer be doing this?" Torvalds, making motions as though he was using a walker, replied, "I would love to still do this conference with you." The report notes the contention around the integration of Rust, highlighted by the recent departure of Rust for Linux maintainer Wedson Filho. Despite resistance from some devs who prefer C and are skeptical of Rust, Torvalds remains optimistic about Rust's future in the kernel.

He said: "Rust is a very different thing, and there are a lot of people who are used to the C model. They don't like the differences, but that's OK. In the kernel itself, absolutely nobody understands everything. I don't. I rely heavily on maintainers of various subsystems. I think the same can be true of Rust and C. I think it's one of our strengths in the kernel that we can specialize. Clearly, some people just don't like the notion of Rust and having Rust encroach on their area. But we've only been doing Rust for a couple of years, so it's way too early to say Rust is a failure."

Meanwhile, Torvalds confirmed that the long-anticipated real-time Linux (RTLinux) project will finally be integrated into the kernel with the upcoming release of Linux 6.12.

Linux creator Linus Torvalds has released version 6.11 of the open-source operating system kernel. The new release, while not considered major by Torvalds, introduces several notable improvements for AMD hardware users and Arch Linux developers. ZDNet: This latest version introduces several enhancements, particularly for AMD hardware users, while offering broader system improvements and new capabilities. These include:
RDNA4 Graphics Support: The kernel now includes baseline support for AMD's upcoming RDNA4 graphics architecture. This early integration bodes well for future AMD GPU releases, ensuring Linux users have day-one support.
Core Performance Boost: The AMD P-State driver now includes handling for AMD Core Performance Boost. This driver gives AMD Core users more granular control over turbo and boost frequency ranges.
Fast Collaborative Processor Performance Control (CPPC) Support: Overclockers who want the most power possible from their computers will be happy with this improvement to the AMD P-State driver. This feature enhances power efficiency on recent Ryzen (Zen 4) mobile processors. This can improve performance by 2-6% without increasing power consumption.
AES-GCM Crypto Performance: AMD and Intel CPUs benefit from significantly faster AES-GCM encryption and decryption processing, up to 160% faster than previous versions.

Last October Slashdot reported on René Rebe's discovery of a random illegal instruction speculation bug on AMD Ryzen 7000-series and Epyc Zen 4 CPUs — which Rebe discussed on his YouTube channel.

But this week's YouTube episode had a different ending, reports Tom's Hardware... Two days ago, tech streamer and host of Code Therapy René Rebe was streaming one of many T2 Linux (his own custom distribution) development sessions from his office in Germany when he abruptly had to remove his microphone and walk off camera due to the arrival of police officers. The officers subsequently cuffed him and took him to the station for an hour of questioning, a span of time during which the stream continued to run until he made it back...

[T]he police seemingly have no idea who did it and acted based on a tip sent with an email. Finding the perpetrators could take a while, and options will be fairly limited if they don't also live in Germany.
Rebe has been contributing to Linux "since as early as 1998," according to the article, "and started his own T2 SD3 Embedded Linux distribution in 2004, as well." (And he's also a contributor to many other major open source projects.)

The article points out that Linux and other communities "are compelled by little-to-no profit motive, so in essence, René has been providing unpaid software development for the greater good for the past two decades."

Efforts to add Rust code to the Linux kernel has suffered a setback as one of the maintainers of the Rust for Linux project has stepped down -- citing frustration with "nontechnical nonsense," according to The Register: Wedson Almeida Filho, a software engineer at Microsoft who has overseen the Rust for Linux project, announced his resignation in a message to the Linux kernel development mailing list. "I am retiring from the project," Filho declared. "After almost four years, I find myself lacking the energy and enthusiasm I once had to respond to some of the nontechnical nonsense, so it's best to leave it up to those who still have it in them."

[...] Memory safety bugs are regularly cited as the major source of serious software vulnerabilities by organizations overseeing large projects written in C and C++. So in recent years there's been a concerted push from large developers like Microsoft and Google, as well as from government entities like the US Cybersecurity and Infrastructure Security Agency, to use memory-safe programming languages -- among them Rust. Discussions about adding Rust to Linux date back to 2020 and were realized in late 2022 with the release of Linux 6.1. "I truly believe the future of kernels is with memory-safe languages," Filho's note continued. "I am no visionary but if Linux doesn't internalize this, I'm afraid some other kernel will do to it what it did to Unix."

New submitter meisdug writes: A new feature has been submitted for inclusion in Linux 6.12, allowing the display of a QR code when a kernel panic occurs using the DRM Panic handler. This QR code can capture detailed error information that is often missed in traditional text-based panic messages, making it more user-friendly. The feature, written in Rust, is optional and can be enabled via a specific build switch. This implementation follows similar ideas from other operating systems and earlier discussions in the Linux community.

An anonymous reader quotes a report from overkill.wtf: The team behind popular emulation tool EmuDeck is today announcing something rather special: they've spent the first half of 2024 working on their very first hardware product, called the EmuDeck Machine, and it's due to arrive before the year is out. This EmuDeck Machine is an upcoming, crowdfunded, retro emulation mini PC running Bazzite, a Linux-based system similar to SteamOS. [...] This new EmuDeck Machine comes in two variants, the EM1 running an Intel N97 APU, and the EM2 -- based on an AMD Ryzen 8600G. While both machines are meant as emulation-first devices, the AMD-based variant can easily function as a console-like PC. This is also thanks to some custom work done by the team: "We've optimized the system for maximum power. The default configuration of an 8600G gets you 32 FPS in Cyberpunk; we've managed to reach 47 FPS with a completely stable system, or 60FPS if you use FSR."

Both machines will ship with a Gamesir Nova Lite controller and EmuDeck preinstalled naturally. The team has also preinstalled all available Decky plugins. But that's not all: if the campaign is successful, the EmuDeck team will also work on a docking station for the EM2 that will upgrade the graphics to an AMD Radeon 7600 desktop GPU. With this, in games like Cyberpunk 2077, you'll be able to reach 160 FPS in 1080p as per EmuDeck's measurements. You can preorder the EmuDeck Machines via Indigogo, starting at $322 and shipping in December.

The Register's Liam Proven reports: Microsoft's in-house professional networking site is moving to Microsoft's in-house Linux. This could mean that big changes are coming for the former CBL-Mariner distro. Ievgen Priadka's post on the LinkedIn Engineering blog, titled Navigating the transition: adopting Azure Linux as LinkedIn's operating system, is the visible sign of what we suspect has been a massive internal engineering effort. It describes some of the changes needed to migrate what the post calls "most of our fleet" from the end-of-life CentOS 7 to Microsoft Azure Linux -- the distro that grew out of and replaced its previous internal distro, CBL-Mariner.

This is an important stage in a long process. Microsoft acquired LinkedIn way back in 2016. Even so, as recently as the end of last year, we reported that a move to Azure had been abandoned, which came a few months after it laid off almost 700 LinkedIn staff -- the majority in R&D. The blog post is over 3,500 words long, so there's quite a lot to chew on -- and we're certain that this has been passed through and approved by numerous marketing and management people and scoured of any potentially embarrassing admissions. Some interesting nuggets remain, though. We enjoyed the modest comment that: "However, with the shift to CentOS Stream, users felt uncertain about the project's direction and the timeline for updates. This uncertainty created some concerns about the reliability and support of CentOS as an operating system." [...]

There are some interesting technical details in the post too. It seems LinkedIn is running on XFS -- also the RHEL default file system, of course -- with the notable exception of Hadoop, and so the Azure Linux team had to add XFS support. Some CentOS and actual RHEL is still used in there somewhere. That fits perfectly with using any of the RHELatives. However, the post also mentions that the team developed a tool to aid with deploying via MaaS, which it explicitly defines as Metal as a Service. MaaS is a Canonical service, although it does support other distros -- so as well as CentOS, there may have been some Ubuntu in the LinkedIn stack as well. Some details hint at what we suspect were probably major deployment headaches. [...] Some of the other information covers things the teams did not do, which is equally informative. [...]

"At The Linux Foundation's Open Source Summit China conference, Linus Torvalds and his buddy Dirk Hohndel, Verizon's Head of the Open Source Program Office, once more chatted about Linux development and related issues," reports ZDNet: Torvalds: "Later this year, we will have the 20th anniversary of the real-time Linux project. This is a project that literally started 20 years ago, and the people involved are finally at that point where they feel like it is done... well, almost done. They're still tweaking the last things, but they hope it will soon be ready to be completely merged in the upstream kernel this year... You'd think that all the basics would have been fixed long ago, but they're not. We're still dealing with basic issues such as memory management...."

Switching to a more modern topic, the introduction of the Rust language into Linux, Torvalds is disappointed that its adoption isn't going faster. "I was expecting updates to be faster, but part of the problem is that old-time kernel developers are used to C and don't know Rust. They're not exactly excited about having to learn a new language that is, in some respects, very different. So there's been some pushback on Rust." On top of that, Torvalds commented, "Another reason has been the Rust infrastructure itself has not been super stable...."

The pair then moved on to the hottest of modern tech topics: AI. While Torvalds is skeptical about the current AI hype, he is hopeful that AI tools could eventually aid in code review and bug detection. In the meantime, though, Torvalds is happy about AI's side effects. For example, he said, "When AI came in, it was wonderful, because Nvidia got much more involved in the kernel. Nvidia went from being on my list of companies who are not good to my list of companies who are doing really good work."

Linux creator Linus Torvalds expressed disappointment with the slow adoption of Rust in the Linux kernel at the Linux Foundation's Open Source Summit China. In a conversation with Verizon executive Dirk Hohndel, Torvalds said, "I was expecting updates to be faster, but part of the problem is that old-time kernel developers are used to C and don't know Rust. They're not exactly excited about having to learn a new language that is, in some respects, very different." This resistance has led to "some pushback on Rust," he said. "Another reason has been the Rust infrastructure itself has not been super stable," he added.

Phoronix's Michael Larabel benchmarked AMD's latest Ryzen 9 9950X in several different Linux distros and found that the Zen 5 chip performs up to 16% faster with the Intel-optimized Clear Linux distro. Here's an excerpt from the report: The Linux distributions for this round of testing on the AMD Ryzen 9 9950X included Arch Linux, CachyOS, Clear Linux, Fedora Workstation 40, Ubuntu 24.04 LTS, and a recent daily snapshot of Ubuntu 24.10 in its current development form. Intel's Clear Linux is the one most interesting for looking at on the new AMD Zen 5 hardware. While there hasn't been so much Clear Linux news in recent times, it remains the most well optimized x86_64 Linux distribution out of the box. Clear Linux makes use of compiler function multi versioning, performance-minded defaults, aggressive compiler CFLAGS/CXXFLAGS defaults, optional AVX-512 usage for more libraries, and many other patches and optimizations in the name of delivering the greatest x86_64 Linux performance. And while not Intel's focus, it works typically on AMD hardware too. [...]

Using the same Ryzen 9 9950X system, all of these Linux distributions were tested in their default / out-of-the-box state. [...] When taking the geometric mean of 59 benchmarks run across all of the Linux distributions on this AMD Ryzen 9 9950X system, Intel's Clear Linux easily took the crown. Ubuntu 24.04 LTS -- which was used for all of the Ryzen 9000 series Linux testing so far on Phoronix -- was the slowest. Tapping Intel's Clear Linux netted a 16% improvement on top of the performance offered by Ubuntu 24.04 LTS! Ubuntu 24.04 with the Ryzen 9000 series was already looking great generationally, but as shown today the performance can be even better with further software optimizations.

The Arch Linux powered CachyOS that is tuned out-of-the-box with a similar aim to Clear Linux also performed great. CachyOS was 7% faster than Ubuntu 24.04 LTS based on the geo mean and 3% faster than upstream Arch Linux itself. For different workloads though the CachyOS advantage over Arch Linux varied from a minimal difference to quite significant advantages. From the performance of PHP and Python scripts atop Clear Linux to compiling various server and HPC minded software, Intel's Clear Linux -- and a commendable second place for CachyOS -- were showing that even greater performance can be achieved on the AMD Ryzen 9 9950X. Even for devoted Ubuntu Linux users, these results did show some nice advantages of the upcoming Ubuntu 24.10 release over Ubuntu 24.04 LTS thanks to the GCC 14 compiler. Ubuntu 24.10 performance is also still subject to change since the current daily ISOs haven't yet moved past the Linux 6.8 kernel while Ubuntu 24.10 in October will be shipping with Linux 6.11.

bobdevine writes: The Linux operating system has reached a notable milestone in desktop market share, according to the latest data from StatCounter. As of July 2024, Linux has achieved a 4.45% market share for desktop operating systems worldwide. While this percentage might seem small to those unfamiliar with the operating system landscape, it represents a significant milestone for Linux and its dedicated community. What makes this achievement even more thrilling is the upward trajectory of Linux's adoption rate.

Ars Technica's Dan Goodwin writes: Last Tuesday, loads of Linux users -- many running packages released as early as this year -- started reporting their devices were failing to boot. Instead, they received a cryptic error message that included the phrase: "Something has gone seriously wrong." The cause: an update Microsoft issued as part of its monthly patch release. It was intended to close a 2-year-old vulnerability in GRUB, an open source boot loader used to start up many Linux devices. The vulnerability, with a severity rating of 8.6 out of 10, made it possible for hackers to bypass secure boot, the industry standard for ensuring that devices running Windows or other operating systems don't load malicious firmware or software during the bootup process. CVE-2022-2601 was discovered in 2022, but for unclear reasons, Microsoft patched it only last Tuesday. [...]

With Microsoft maintaining radio silence, those affected by the glitch have been forced to find their own remedies. One option is to access their EFI panel and turn off secure boot. Depending on the security needs of the user, that option may not be acceptable. A better short-term option is to delete the SBAT Microsoft pushed out last Tuesday. This means users will still receive some of the benefits of Secure Boot even if they remain vulnerable to attacks that exploit CVE-2022-2601. The steps for this remedy are outlined here (thanks to manutheeng for the reference).

Here's a question from the blog OMG Ubuntu. "Ever get miffed reading about a major new Ubuntu release only to learn it doesn't come with the newest Linux kernel?

"Well, that'll soon be a thing of the past." Canonical's announced a big shift in kernel selection process for future Ubuntu release, an "aggressive kernel version commitment policy" pivot that means it will ship the latest upstream kernel code in development at the time of a new Ubuntu release.

Yes, even if that upstream kernel hasn't yet seen a formal stable release (and received the requisite newspaper-graphic-topped rundown on this blog). Which is a huge change. Currently, new Ubuntu releases include the most recent stable Linux kernel release at the time of the kernel freeze milestone in the Ubuntu development cycle.
Here's the official announcement by Canonical's Brett Grandbois. "Ubuntu will now ship the absolute latest available version of the upstream Linux kernel at the specified Ubuntu release freeze date, even if upstream is still in Release Candidate status..." It is actually expected that Late Releases will be the exception rather than the norm and in most releases these guidelines will not be necessary as the upstream kernel will release with enough time for the Ubuntu kernel to stabilize. However, adopting a more aggressive kernel version commitment policy does require us to be prepared for a possible Late Release situation and therefore informing the community on what they can expect.

Michael Larabel reports via Phoronix: Intel Linux engineer Colin Ian King discovered that if aligning the slab in the ACPI code via the "SLAB_HWCACHE_ALIGN" flag will offer a measurable improvement in memory performance and reducing the kernel boot time.

Colin explained with this one line kernel patch: "Enabling SLAB_HWCACHE_ALIGN for the ACPI object caches improves boot speed in the ACPICA core for object allocation and free'ing especially in the AML parsing and execution phases in boot. Testing with 100 boots shows an average boot saving in acpi_init of ~35000 usecs compared to the unaligned version. Most of the ACPI objects being allocated and free'd are of very short life times in the critical paths for parsing and execution, so the extra memory used for alignment isn't too onerous."