There have been claims that the fixes for the Meltdown and Spectre security vulnerabilities, named the KPTI (aka KAISER) patches, are going to affect application performance by 10-30 percent. The patch makes any call from user space into the operating system much more expensive, so I/O intensive applications are likely to be the worst hit. What does this really mean for HPC workloads?

Optimisation has always been important to HPC, but the new patches have moved the goal posts. Profiling applications and how they access data on disk and over the network is going to be key to getting a handle on what the worst problems are going to be. Losing a third of your compute overhead is an understandably scary prospect, but this doesn’t have to be a thoroughly lose-lose situation.

Consider the following aspects of your workloads now to mitigate potential performance damage as much as possible.

1.     Our workflows use third-party tools – there’s nothing I can do, right?

It’s common to use a mix of third-party and in-house tools. Optimising in-house applications is a resourcing issue, but possible. When third-party tools have performance problems, you are often on your own, even if they are open source.

It is, however, still worth investigating performance drops of third-party workflows. As well as being able to feed data back to your vendor or to the user community, there are always changes you can make to the way a program runs that affects the I/O. For example, do you use environment variables to configure that application? Long PATH variables and similar settings can cause applications to trawl the file system with sequences of failed open() or stat() calls many times in a single execution.

These failed I/O calls or distributed accesses cause problems for shared file systems even before you have installed the KPTI patch. Once the patch has been applied it’s likely that the affect of those unnecessary meta data operations will increase for the program performing them as well as for the shared file system struggling under the load.

So even if you have a workflow with just a wrapper script to launch it and a single third-party binary that won’t ever be updated, it is still a very good idea to work out where you are spending your time. Even something as simple as moving temporary files from shared to local storage is likely to give you a win.

2.     Genome pipelines and other fans of small files

Genome pipelines are well known for using a lot of small files to map DNA segments against a reference genome. Other HPC applications in oil and gas, EDA and finance sometimes do the same. Part of the reason for this is a need to honour legacy working practices because in science it can be hard to prove the validity of your work if it is using entirely new software, but it’s also a limitation of the algorithms used in these applications.

Small files necessarily mean small I/O and lots of meta data, but worse than that, often small files are accessed in smaller chunks, further exacerbating the problem. Why is this a problem? Let’s assume that small I/O is anything under 32KB, depending on the architecture of your system. Files under 4KB can be easily written off as an unsolvable problem, but if you access the data in less than 4KB blocks then there is definitely scope for the problem to be a lot worse than it needs to be. Closing a file after every small write or checking the existence of every file before opening it will also magnify the performance impact of the security patches.

Small I/O isn’t limited to applications that use small files. Older libraries and code that hasn’t been profiled will often use system calls that perform small reads and writes. Sometimes gigabytes of data are read or written one byte at a time. This behaviour is very common in almost all compute environments and will be catastrophic for local performance as well as any shared file system or database.

3.     Will the performance drop caused by the patches impact local or shared storage the most?

Reports so far of the impact of the patches on shared file systems have not been good. In time, those who maintain the file system will be able to make some performance improvements based on the new compute landscape, but no one is going to be able to escape the performance drop entirely. Shared storage is an important part of most HPC clusters and cloud infrastructure. When accessing anything remotely there will be a performance hit over local storage, but the KPTI patch will be hitting performance at both ends.

Some workloads will be slowed down mainly by their own behaviour and I/O patterns. This is good news for the shared file system because anything that throttles accesses gives the file system a bit more time to keep up.

Unfortunately, I/O intensive workloads that have bad local performance are also likely to be those hitting the file system the hardest and will be the worst affected by any slow down of the file system. The only way to know the impact of the patch on your cluster and workloads is to try it and measure it; the complexity of modern HPC systems means that an effect on one resource cannot predict the performance of another.

4.     My application doesn’t do that much I/O so do I still have to worry?

Much has been made of the effect the KPTI patches will have on I/O performance, but the impact will be seen on all system calls. This means calls such as gettimeofday() will get more expensive. Applications with strict timing constraints will make lots of such calls and may well have poorly constructed timing constraints broken by the new delays in accessing even small amounts of data.

Ask yourself, does you program really need that fancy progress bar? You could be paying a lot more for features like this in the future.

5.    Is MPI I/O better or worse?

HPC applications don’t just do POSIX I/O: MPI libraries are a popular way of sharing data and coordinating applications across many thousands of compute ranks. All MPI libraries use POSIX I/O underneath the hood, perhaps not a surprise to many, but what will surprise some is the way they do it.

MPI libraries have evolved over time and seemingly similar calls can have very different implementations with varying reliance on small system calls. We are back to discussing small I/O because high-level constructs such as tables and matrices of data are often accessed with very small reads and writes.

The good news is that many MPI libraries are binary compatible for the most part, so changing the library once a performance problem has been identified is not as difficult as optimising other types of I/O, but it is something that you may not have control over. Artificial benchmarks such as IOR that let you compare MPI libraries are unlikely to give you much insight into the real impact of the KPTI patch because real workloads are so different from the orderly I/O that those benchmarks stress. Again, the only way to find out where time is being spent is to profile a real application.

6.     Can I escape the problem by moving my workloads to the cloud?

Unfortunately, virtualised workloads are still affected by the vulnerability and need to be patched. That goes for containerised workloads as well.

Moving applications to the cloud usually involves some kind of re-architecture to reduce the reliance on shared storage and to take advantage of the high-performance and low-cost storage options available. Getting a handle on how your applications use storage and where their dependencies are is part of this process, so optimising for the KPTI patch is work that can almost come for free as part of the efforts to embrace the future. Some I/O patterns will be worse in the cloud and some will be better, but that was true before anyone knew about Meltdown and Spectre.

So all in all, HPC applications are going to be affected by the patches in varying degrees. The cheerful news is that a lot of the impact on performance can be mitigated by optimisation efforts where the resources are available. Using third-party tools and libraries doesn’t render you helpless – there still might be room for easy wins in performance.

Let’s hope that the situation doesn’t become even more complicated as the HPC industry works to come with more solutions. Given the complexity of most HPC workloads and systems already, anything that can be done to simplify and optimise systems rather than add layers of fixes will surely be good for future growth.

About the Author

Dr. Rosemary Francis is CEO and founder of Ellexus, the I/O profiling company (www.ellexus.com). Ellexus makes application profiling and monitoring tools that can be run on a live compute cluster to protect from rogue jobs and noisy neighbours, make cloud migration easy and allow a cluster to be scaled rapidly. The system- and storage-agnostic tools provide end-to-end visibility into exactly what applications and users are up to. We don’t just give you data about what your programs are doing; our tools include expertise on what is going wrong and how you can fix it.