Whatever machine you’re reading this on, it’s highly likely that not all of the CPUs shown by the OS are actually physical processors. That’s because most modern processors use simultaneous multithreading (SMT) to improve performance by executing tasks in parallel.

Intel’s implementation of SMT is known as hyperthreading, and it was originally introduced in 2002 as a way to improve the performance of Pentium 4 and Xeon CPUs that didn’t require increasing the clock frequency. Most Intel CPUs supported the HyperThread Technology (HTT) apart from the Core line of products until the Nehalem microarchitecture which was introduced in 2008. Recently, Intel have announced that they’re moving away from hyperthreading again with their Core product line.

AMD too have dabbled with SMT, and the diagram below shows how SMT works in the Zen microarchitecture.

As the diagram above illustrates, some components are dedicated to each thread and some are shared. Which pieces are shared? That depends on the implementation and can potentially vary with the microarchitecture. But it’s usually some part of the execution unit.

SMT threads usually come in pairs for x86 architecture, and those threads contend with their siblings for access to shared processor hardware. By using SMT you are effectively trying to exploit the natural gaps in a thread’s hardware use. Or as Pekka Enberg eloquently put it:

There are both good and bad reasons to use SMT.

Why is SMT good?

SMT implementations can be very efficient in terms of die size and power consumption, at least when compared with fully duplicating processor resources.

With less than a 5% increase in die size, Intel claims that you can get a 30% performance boost by using SMT for multithreaded workloads.

What you’re likely to see in the real world depends very much on your workload, and like all things performance-related, the only way to know for sure is to benchmark it yourself.

Another reason to favour SMT is that it’s now ubiquitous in modern x86 CPUs. So it’s an easy, achievable way to increase performance. You just need to make sure it’s turned on in your BIOS configuration.

Why is SMT bad?

One of the best and also worst things about SMT is that the operating system doesn’t make it obvious when SMT is enabled. Most of the time, that’s good because it’s an unnecessary distraction. But when it comes to things like capacity planning, or tuning your system for real-time workloads, you really need to know if SMT is enabled.

Take assigning physical CPUs to virtual machines, for example. If you’re not aware that SMT is turned on, it’s easy to think that doubling the number of CPUs will double the performance, but that’s almost certainly not going to be the case if those CPUs are actually SMT siblings because they will be contending for processor resources.

Modern x86 processors come with so many cores (the new AMD Rome CPUs processors have 64 and top-line Intel Core i9 CPUs now have 18) that there’s plenty of performance to be had without enabling SMT.

But perhaps the biggest reason against SMT, and this is definitely the Zeitgeist, is the string of security vulnerabilities that have been disclosed over the last year or so, including L1TF and MDS.

OpenBSD was the first operating system to recommend disabling SMT altogether in August 2018 because they feared that more vulnerabilities would be discovered in this area. They were right.

Greg Kroah Hartman gave a shout out to OpenBSD’s forward thinking in his Open Source Summit talk last month where he said that he had “huge respect” for the project because they made a tough call and chose security over performance.

How to disable SMT

Many users are also now considering disabling SMT all together. Whether or not you’re willing to do that depends on your individual circumstances.

But if you are thinking about it, you’ll need to run benchmarks to understand the performance impact. Which means you’ll need a handy way to run with SMT on and off.

This is usually done in the BIOS setup but if you can’t access it – and if you’re running Linux – you can disable it by writing “off” to the /sys/devices/system/cpu/smt/control file, e.g.

$ nproc
4
$ echo off > /sys/devices/system/cpu/smt/control
$ nproc
2

To re-enable SMT you just need to write “on” to the same file.

So does SMT still make sense? There’s no reason to think that we’ve seen the last of chip-level security vulns, so if you’re at all concerned about security then the safest best is to run with SMT disabled. If you’re concerned about losing performance, you need to get to running those benchmarks.

Thanks to Senior Lecturer and Programme Coordinator, Aditya Santokhee, at the Middlesex University Mauritius, my colleague Chittesh & I got to deliver guest talks at the university today.

Chittesh, also our local Mozillian, spoke about the Internet Health Report and raised privacy concerns surrounding major online platforms. He mentioned the Cambridge Analytica scandal in particular, especially how that raised public awareness about digital privacy. He added that following the enforcement of the European Union's General Data Protection Regulations (EU GDPR), tens of thousands of violation complaints have been filed. Google was fined €50 million for GDPR violations in France.

His talk was more a message to the young students for them to review their online habits and take a moment to think about digital privacy.

On the other hand I had a semi-technical talk about Pods & Containers. Although we had a lecture theatre fully packed with Computer Science students, I was told they were mostly in second year, I realise that not everyone would be acquainted to Linux containers, or yet Linux itself.

Therefore, I started with a gentle introduction about operating systems and where Linux stands. I asked the students whether they are familiar with virtualization and part of the room answered yes. It made it easier to compare between having an "architecture emulator" to run a virtual machine and a simple isolated environment comprising of a bunch of files. That's the simplest explanation I could give to make the students comfortable with the idea of containers.

Then, I moved to the topic of Podman, while doing some demos and helping the students learn how podman run ... could make things easier for them. I asked them a few questions about university assignments such as developing an application and the need of having an "environment" to build or test the application. Instead of having a full Linux environment with a bunch of packages installed & configured simply to serve a web application, a single-line of podman could serve those files in an Nginx container. Especially, doing this without a big-fat-daemon, pun intended! 🤓

I briefly talked about Skopeo and I invited the more adventurous students to peek inside of containers and get a better understanding of what they are made of. The key lesson being, magic is for the users not for the engineer.

I ended the talk with this nice slide copied from my openSUSE MicroOS workshop deck from the openSUSE Asia Summit 2019. 😊

Slides available at speakerdeck.com/ishwon/podman-101.

Introduction

It’s time for another YaST team report! Let’s see what’s on the menu today.

• More news and improvements in the storage area, specially regarding encryption support.
• Some polishing of the behavior of YaST Network.
• New widgets in libYUI.
• A look into systemd timers and how we are using them to replace cron.
• And a new cool tool for developers who have to deal with complex object-oriented code!

So let’s go for it all.

Performance Improvements in Encrypted Devices

As you may know, we have recently extended YaST to support additional encryption mechanisms like volatile encryption for swap devices or pervasive encryption for data volumes. You can find more details in our blog post titled "Advanced Encryption Options Land in the YaST Partitioner".

Those encryption mechanisms offer the possibility of adjusting the sector size of the encryption layer according to the sector size of the disk. That can result in a performance boost with storage devices based on 4k blocks. To get the best of your systems, we have instructed YaST to set the sector size to 4096 bytes whenever is possible, which should improve the performance of the encrypted devices created with the recently implemented methods.

Additionally, we took the time to improve the codebase related to encryption, based on the lessons we learned while implementing volatile and pervasive encryption. We also performed some additional tests and we found a problem that we are already fixing in the sprint that has just started.

Other improvements related to encryption

One of those lessons we have learnt recently is that resizing a device encrypted with a LUKS2 encryption layer works slightly different to the traditional LUKS1 case. With LUKS2 the password must be provided in the moment of resizing, even if the device is already open and active. So we changed how libstorage-ng handles the passwords provided by the user to make it possible to resize LUKS2 devices in several situations, although there are still some cases in which it will not be possible to use the YaST Partitioner to resize a LUKS2 device.

As a side effect of the new passwords management, now the process that analyzes the storage devices at the beginning of the installation should be more pleasant in scenarios like the one described in the report of bug#1129496, where there are many encrypted devices but the user doesn’t want to activate them all.

And talking about improvements based on our users’ feedback, we have also adapted the names of the new methods for encrypting swap with volatile keys, as suggested in the comments of our already mentioned previous blog post. We also took the opportunity to improve the corresponding warning messages and help texts.

Network and Dependencies Between Devices

Similar to encryption, the network backend is another area that needed some final adjustments after the big implementation done in the previous sprints. In particular, we wanted to improve the management of devices that depend on other network devices, like VLANs (virtual LANs) or bridges.

Historically, YaST has simply kept the name of the device as a dependency, even if such device does not exist any longer. That leaded to inconsistent states. Now the dependencies are updated dynamically. If the user renames a device, then it’s automatically renamed in all its dependencies. If the user deletes a device that is needed by any other one, YaST will immediately ask the user whether to modify (in the case of bonding and bridges) or to remove (in the case of VLANs) those dependent devices.

New libYUI Widget: ItemSelector

Now that we mention the user experience, it’s fair to note that it has been quite a while since we created the last new widget for libYUI, our YaST UI toolkit. But we identified a need for a widget that lets the user select one or many from a number of items with not only a short title, but also a descriptive text for each one (and optionally an icon), and that can scroll if there are more items than fit on the screen.

So say hello to the new SingleItemSelector.

As you would expect from any libYUI widget, there is also a text-based (ncurses) alternative.

Please, note the screenshots above are just short usage examples. We are NOT planning to bring back the desktop selection screen. On the other hand, now we have the opportunity to make a prettier screen to select the computer role. Stay tuned for more news about that.

There is also an alternative version of the new widget that allows to select several items. The unsurprisingly named MultiItemSelector.

Which, of course, also comes with an ncurses version.

In the near future, we are planning to use that for selecting products and add-on modules. But this kind of widgets will find other uses as well.

Fun with Systemd Timers

And talking about the close future, many of you may know there is a plan coming together to replace the usage of cron with systemd timers as the default mechanism for (open)SUSE packages to execute periodic tasks.

In our case, we decided to start the change with yast2-ntp-client, which offers the possibility to synchronize the system time once in a while. So let’s take a look to how systemd timers work and how we used them to replace cron.

When defining a service in systemd it is possible to specify a type for that service to define how it behaves. When started, a service of type oneshot will simply execute some action and then finish. Those services can be combined with the timers, which invoke any service according to monotonous clock with a given cadence. To make that cadence configurable by the user, the YaST module overrides the default timer with another one located at /etc/systemd/system.

As a note for anyone else migrating to systemd timers, our first though was to use the EnvironmentFile directive instead of overriding the timer. But that seems to not be possible for timers.

One clear advantage of using a systemd service to implement this is the possibility of specifying dependencies and relations with other services. In our case, that allows us to specify that one time synchronization cannot be used if the chrony daemon is running, since they would both conflict. So the new system is slightly more complex than a one-liner cron script, but it’s also more descriptive and solid.

And another tip for anyone dealing with one-shot services and systemd timers, you can use systemd-cat to catch the output of any script and redirect it to the systemd journal.

Everybody Loves Diagrams

But apart from tips for sysadmins and packagers, we also have some content for our fellow developers. You know YaST is a huge project that tries to manage all kind of inter-related pieces. Often, the average YaST developer needs to jump into some complex module. Code documentation can help to know your way around YaST internals that you don’t work with every day. To generate such documentation, we use the YARD tool, and its output is for example here, for yast-network. Still, for large modules with many small classes, this is not enough to get a good overview.

Enter yard-medoosa, a plugin for YARD that automatically creates UML class diagrams, clickable to get you to the classes textual documentation.

It is still a prototype but it has proven useful for navigating a certain large pull request. We hope to soon tell you about an improved version.

More Solid Device Names in fstab and crypttab

Back to topics related to storage management, you surely know there are several ways to specify a device to be mounted in the /etc/fstab file or a device to be activated in the /etc/crypttab. Apart from using directly the name of the device (like /dev/sda1) or any of its alternative names based on udev, you can also use the UUID or the label of the file-system or of the LUKS device.

By default, YaST will use the udev path in s390 systems and the UUID in any other architecture. Although that’s something that can be configured modifying the /etc/sysconfig/storage file or simply using this screen of the Partitioner, which makes possible to change how the installation (both the Guided Setup and the Expert Partitioner) writes the resulting fstab and crypttab files.

But, what happens when the default option (like the udev path) is not a valid option for some particular device? So far, YaST simply used the device name (e.g. /dev/sda1) as an immediate fallback. That happened at the very end of the process, when already writing the changes to disk.

We have improved that for Tumbleweed, for SLE-15-SP1 (which implies Leap 15.1) and for the upcoming versions of (open)SUSE. Now, if the default value is not suitable for a particular device because the corresponding udev path does not exists, because using a given name is incompatible with the chosen encryption method, or for any other reason, YaST will fall back to the most reasonable and stable alternative. And it will do it from the very beginning of the process, being immediately visible in the Partitioner.

Stay Tuned for More… and Stay Communicative

As usual, when we publish our sprint report we are already working on the next development sprint. So in approximately two weeks you will have more news about our work, this time likely with a strong focus in AutoYaST.

Don’t forget to keep providing us feedback. As commented above, it’s very valuable for us and we really use it as an input to plan subsequent development sprints.

The openSUSE project informed it's members by mail to vote for a potential name change. The vote ends on 07.11.2019 at 23:59 UTC. In a Wiki article the openSUSE Board and Election Committee have gathered the most important arguments for and against a name change for all members.

The background

In an article the media platform Heise already reported on 12.06.2019 that the openSUSE project is going to build a foundation and might also consider a name and logo change in the process.

T...

Intro

Our Container Host OS openSUSE MicroOS and our Kubernetes platform openSUSE Kubic are both using transactional-update to apply patches to the system. This implies that a read-only root filesystem is used. While this has big advantages, like it allows to update a cluster automatically in a safe way, this has one drawback: you need to reboot to activate new installed packages. But what if you want to debug a problem and the utility you need is not installed? Who says, that the problem is still debuggable after a reboot?

For this, we introduced now the toolbox utilitiy with a toolbox container.

toolbox - bring your own tools with you

toolbox is a small script that launches a privileged container to let you bring in your favorite debugging or admin tools in such a system. If the container does not contain the utility you need, you can install whatever you want with zypper. toolbox is stateful, if you quit the script and start it later again, the environment is in the exactly same state as when you left it. To reset it, the container image needs to be deleted: podman rm toolbox-<user>. The root filesystem can be found at /media/root.

Usage

$ /usr/bin/toolbox
Spawning a container 'toolbox-root' with image 'registry.opensuse.org/opensuse/toolbox'
51e475f05d8bb8a5bf110bbecd960383bf8cfade1569587edef92076215f0eba
toolbox-root
Container started successfully. To exit, type 'exit'.
toolbox:/ # ls -alF /media/root
...
toolbox:/ # tcpdump -i ens3
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ens3, link-type EN10MB (Ethernet), capture size 65535 bytes
...
toolbox:/ # zypper in vim
Loading repository data...
Reading installed packages...
Resolving package dependencies...

The following 5 NEW packages are going to be installed:
  libgdbm6 libgdbm_compat4 perl vim vim-data-common

5 new packages to install.
Overall download size: 9.0 MiB. Already cached: 0 B. After the operation,
additional 49.4 MiB will be used.
Continue? [y/n/v/...? shows all options] (y):
...
toolbox:/ # vi /media/root/etc/passwd

Advanced Usage

Use a custom image

toolbox uses an openSUSE-based userspace environment called opensuse/toolbox by default, but this can be changed to any container image. Simply override environment variables in $HOME/.toolboxrc, where every entry is optional:

toolbox configuration file

# cat ~/.toolboxrc
REGISTRY=registry.opensuse.org
IMAGE=opensuse/toolbox:latest
TOOLBOX_NAME=special-debug-container
TOOLBOX_SHELL="/bin/bash"

Root container as normal user

toolbox called by a normal user will start the toolbox container, too, but the root filesystem cannot be modified. Running toolbox with sudo has the disadvantage, that the .toolboxrc from root and not the user is used. To run the toolbox container with root rights, toolbox --root has to be used.

Automatically enter toolbox on login

Set an /etc/passwd entry for one of the users to /usr/bin/toolbox:

useradd bob -m -s /usr/bin/toolbox

Now when SSHing into the system as that user, toolbox will automatically be started:

# ssh bob@hostname.example.com
Last login: Thu Oct  3 16:52:16 2019 from 192.168.107.1
.toolboxrc file detected, overriding defaults...
Container 'toolbox-bob' already exists. Trying to start...
(To remove the container and start with a fresh toolbox, run: podman rm 'toolbox-bob')
toolbox-bob
Container started successfully. To exit, type 'exit'.
toolbox:/ #

I’ve created an appimage here for the various admin tools modules I’ve been working on. I wrote a previous blog article about this, but I lost some history when I borked my wordpress database and didn’t have a backup.