Tag Archives: Revised

“VIRTME” Revised For Virtualized Linux Kernel Testing


The “VIRTME” project was started years ago as a set of simple tools for running a virtualized Linux kernel that uses the host distribution or basic root file-system rather than a complete Linux distribution image. There hasn’t been a new release of VIRTME in years but that changed on Thursday.

VIRTME is focused on providing a very basic virtualization setup for quickly and easily testing Linux kernel changes without the overhead of setting up a complete virtualization stack. Developers behind VIRTME also talked previously of spinning this into a sandbox-type environment.

Up until yesterday the last release of VIRTME was v0.0.1 back in 2014, but now that was succeeded by VIRTME v0.1 on Thursday (as well as a v0.1.1 due to a bug getting into that release).

VIRTME continues to be developed by Andy Lutomirski and other upstream kernel developers. In recent weeks development on it picked up with the addition of RISC-V support, various clean-ups, better kernel module handling, and a wide range of new options supported. Since v0.0.1 has also been POWERPC64 and SPARC64 support among other additions in recent years.

Those wanting to learn about the new and improved VIRTME can do so via its Kernel.org Git repository.

A Year Later, Speculative Page Fault Code Revised For Possible Performance Benefits


It’s been nearly one year already since the previous patch series working on speculative page faults for the Linux kernel were sent out for review. Fortunately, IBM’s Laurent Dufour has once again updated these patches against the latest code and sent them out for the newest round of discussions.

The simple summary is the set of 31 kernel patches can potentially improve concurrency for highly threaded processes. The improvement comes by handling user-space page faults without holding the mmap semaphore and in turn eliminating some waits within the page fault handler.

When using a “popular in memory multi-threaded database product”, IBM found the Linux performance with earlier revisions of these patches to be up by as much as 30% better in transactions per second. They are still testing these new “v12” patches but are hoping for a similar outcome.

More details via this patch message. Assuming the performance benefits pan out, hopefully it won’t be another year before seeing the next round of revisions or finding the code mainlined within the Linux kernel.

Patches For The Better Spectre STIBP Approach Revised – Version 7 Under Review


Version 7 of the task property based options to enable Spectre V2 userspace-userspace protection patches, a.k.a. the work offering improved / less regressing approach for STIBP, is now available for testing and code review.

Tim Chen of Intel sent out the seventh revision to these patches on Tuesday night. Besides the Spectre V2 app-to-app protection modes, these patches include the work for disabling STIBP (Single Thread Indirect Branch Predictors) when enhanced IBRS (Indirect Branch Restricted Speculation) is supported/used, and allowing for STIBP to be enabled manually and just by default for non-dumpable tasks.

The STIBP patches will no longer take the “big hammer” approach for cross-hyperthread Spectre Variant Two mitigation so the performance hit isn’t across the board but restricting it to non-dumpable tasks like OpenSSH rather than for every process as is currently done with Linux 4.20 Git and back-ported series like Linux 4.19.2+.

With the new V7 patches there is protection for SECCOMP tasks, bug fixes, updated the boot options to align with the other speculation mitigations, disabling the SMT code paths when irrelevant for the current system configuration, and other code changes. All the details can be found via this patch series.

While Linus Torvalds a few days ago criticized the current STIBP approach, he stopped short of calling for it to be reverted right away but is certainly wanting the default behavior to change, which will be by this patch series. However, until this patch series is ready for merging, Tim Chen is calling for the current STIBP code to be reverted. He noted, “Since Jiri’s patchset to always turn on STIBP has big performance impact, I think that it should be reverted from 4.20 and stable kernels for now, till this patchset to mitigate its performance impact can be merged with it.

Greg KH did release Linux 4.19.3 this morning and other stable point releases, but the STIBP code hasn’t been touched with today’s updates. Hopefully it won’t be much longer though until these cleaned up patches are mainlined as the current performance overhead is significant.