Tag Archives: Approach

An (Ir)rational Approach to Interoperability – Interop 2019 Keynote | IT Infrastructure Advice, Discussion, Community

In his Interop19 keynote address, Brian McCarson, Vice President & Senior Principal Engineer, Industrial Solutions Division Internet of Things Group, Intel Corporation, discusses the many challenges with trying to drive openness in a world of walled gardens. But, those challenges are well worth taking on. Proprietary and open systems are not mutually exclusive. There is a rational approach to interoperability that can strike a balanced approach that enables consumer choice and proprietary value. Designing with openness and partnerships in mind will derive greatest value for your enterprise and the ecosystem.

Source link

OpenSUSE’s Spectre Mitigation Approach Is One Of The Reasons For Its Slower Performance


OpenSUSE defaults to IBRS for its Spectre Variant Two mitigations rather than the Retpolines approach and that is one of the reasons for the distribution’s slower out-of-the-box performance compared to other Linux distributions.

A Phoronix reader pointed out this opensuse-factory mailing list thread citing a “huge single-core performance loss” on a Lenovo laptop when using openSUSE. There’s a ~21% performance loss in single-threaded performance around the Spectre Variant Two mitigations, which itself isn’t surprising as we’ve shown time and time again about the performance costs of the Spectre/Meltdown mitigations.

OpenSUSE’s kernel is using IBRS (Indirect Branch Restricted Speculation) with the latest Intel CPU microcode images while most Linux distributions are relying upon Retpolines as return trampolines. The IBRS mitigation technique has the potential of incurring more of a performance loss than Retpolines, which has been known to incur a greater performance hit due to the more restricted speculation behavior when paired with the updated Intel CPU microcode.

Switching over to Retpolines for the workload in question restored the performance, per the mailing list discussion.

OpenSUSE users wanting to use that non-default approach can opt for it using the spectre_v2=retpoline,generic kernel command line parameter, which matches the behavior of most other Linux distributions’ kernels.

As for openSUSE changing their defaults, at least from the aforelinked mailing list discussion it doesn’t appear their kernel engineers have any interest in changing their Spectre mitigation default but are just blaming the poor performance on Intel as their problem.

Some have also suggested the openSUSE installer pick-up a toggle within its installer for informing users of security vs. performance preferences in better providing sane/informed defaults, but so far we haven’t seen any action taken to make that happen. It would make sense though considering some of openSUSE’s conservative defaults do have performance ramifications compared to most other Linux distributions, which we’ve shown in past benchmarks, albeit just written off by openSUSE as “mostly crap.”

Previously a barrier to Retpolines usage was needing the Retpolines compiler support, but that support has now been available for quite some time. There was also reported Retpolines issues with Skylake in the past, but those appear to have been resolved as well.

Fedora’s FESCo Approves Of A “Sane” Approach For Counting Fedora Users Via DNF


Monday’s weekly Fedora Engineering and Steering Committee approved of a means for the DNF package manager to integrate some user counting capabilities as long as it’s a “sane” approach and not the UUID-driven proposal originally laid out.

Originally the plan was to come up with a new UUID identifier system just for counting Fedora users so those in the Fedora project and at Red Hat can have a better idea for the number of Fedora users and other insights. But the concept of having a unique identifier for Fedora users wasn’t well received, even if it was trying to not track users or reveal other personal information.

Baked over the past month was a new privacy-minded plan for counting users via DNF that relies upon a “countme” bit that will be incremented weekly or so and not have any UUID as originally envisioned. See that earlier article for more details on this current plan.

During Monday’s FESCo meeting, the members voted in favor of the plan as long as “the actual implementation is sane.” That was laid out in the meeting minutes.

We’ll see if this new DNF “countme” user counter gets wrapped up time for this spring’s Fedora 30 release or will be delayed until Fedora 31 in the autumn. At the FESCo meeting they also officially approved having GCC 9 be the default system compiler, which was widely expected anyhow given their preference for always shipping with the latest GNU compiler and in fact the developers had already landed the new compiler into Rawhide in its near-final state.

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.