Frank Soltis Discusses A Possible Future for Single-Level Storage
November 23, 2020 Alex Woodie
Single-level storage is one of the most unique and compelling characteristics of the architecture underlying the IBM i server and its predecessor business machines. But how would it look running in a massive supercomputer or deep learning system? According to Frank Soltis, who spoke last week at COMMON Europe’s virtual event, it’s something that’s being considered.
Doctor Frank, of course, is a much-revered figure in the history of the IBM midrange line. He was part of the team at the IBM lab in Rochester, Minnesota, that led the development of the single-level storage memory architecture in the S/38 machine that launched in 1978 and which, as we know, morphed into the AS/400 in 1988. Soltis is retired now, but he’ll always be known as the father of the AS/400.
COMMON Europe invited Soltis to speak during last week’s virtual COMMON Europe Congress (vCEC 2020) event, and Soltis decided to talk about the history of single-level storage, which of course is the system that blends memory and spinning disk into one seamless whole. In many ways, single-level storage is the IBM i-gift that keeps on giving – it is, more than anything else, what differentiates IBM i servers from all the other systems out there.
As a young systems architect, Soltis’s first assignment after joining IBM in 1969 was to come up with the design for the next iteration of the System/3X line. As he explained to the vCEC audience, he never much liked the virtual memory approach that IBM had taken with System/360 Model 67, which was the first IBM system to use virtual memory, and others that came before that.
While the adoption of virtual memory in that old mainframe did enable it to process transactions –which was the main driver for adopting virtual memory in the first place – Soltis did not care for the complexity that accompanied the implementation, and so he was determined to take the System/38 in a different direction.
“When I was back in school a number of years ago, I was studying how the industry, including IBM, had implemented virtual memory, and I came to a fundamental decision in my own mind that they did it wrong,” Soltis said.
“Rather than taking a part of the total memory, the total storage, and just saying, okay this little piece is going to be virtual, and then we’ll have some sort of a file system next to it, which will address completely differently. And we’ll move from that file system into the virtual memory and from the [virtual] memory into the memory, and into the cache, and finally into the processors. Which is wrong.”
The simpler and better way to do it, he said, was just to have one very large pool of memory, Soltis said. “Now that memory had to have certain characteristics,” he continued. “It had to be byte-addressable, because we wanted the byte addressing from the processors to directly address any byte in that memory. It also had to be non-volatile.”
To open up the flow of bits within the system and enable real-time interactive transaction processing – which was the whole point of the exercise – the memory system had to be more adaptable and better able to deal with multiple users and multiple tasks. In the mainframe’s virtual memory approach, it took a thousand instructions to switch from one user to another.
“Now, a thousand instructions is an awful lot. But they had to do a lot,” Soltis said. “In the System/38, or an AS/400 or an IBM i, it takes one instruction. You simply branch to location within that huge storage and begin to execute instructions. It’s a branch. It’s the fastest in the industry.”
While that simple branching technique could theoretically open the memory up to working faster, it also raised potential security risks, Soltis said. If all you had to do was direct an instruction at a particular address, then what’s to prevent a malicious user or piece of malware from accessing that space?
To counteract that, Soltis and his team designed an object-based operating system. “That’s the reason why everything is our system is packaged in an object, because to store it in single-level storage, it has to have a level of protection, and we protect it within an object, object and pointers,” he said. “Pointers contain the address. Pointers contain authorities. What you can do with that particular object, what it’s allowed to do with it.”
That’s the story behind the single-level storage in the IBM i server. But why is that important today? Apparently, it’s because some of the smartest folks developing the next-generation of supercomputer and AI systems today have contacted Soltis to inquire about his approach to single-level storage, and how he came upon this idea more than 40 years ago.
“I maintain a number of contacts with technical people around the world, computer people, and some of the things that doing and what they’re looking at,” he said. “I started to receive some calls about 18 months ago asking me why did we put single-level storage in a small business computer?”
To Soltis and his team, the System/38 wasn’t tiny. Sure, it may be small when stood up next to some of the biggest computers of its day, which took up rooms. Or for that matter, the biggest computers of today, which also take up rooms. But it was the biggest system to come out of Rochester at the time.
“And my answer is always the same: It’s because we wanted to design a system that was designed for interactive processing,” Soltis said.
Spurred by these calls, Soltis dug up some of the technical papers that he wrote back in the day describing single-level storage, which was the topic of his PhD dissertation. He wrote more papers than he can count, and has 25 patents to his name. But that was many years ago, and so he needed a little refresher on some of the specifics to help these folks from government supercomputer labs, universities, and independent research labs who were looking Soltis up and checking out IBM patents around single-level storage.
“IBM holds the patent on single-level storage, and if you look at the patents, they belong to IBM but some of them have my name on it,” he said. “Some of the technical conferences that I’ve spoken at, some of the technical papers that I have written back after we announced the System/38 . . . I have to admit, I pulled them out and started reading them myself, as to what did I say about this thing!”
There have been other attempts to create virtual memory systems, such as single-level storage. Some may call it universal storage, or universal addressability. Intel has a similar approach with its Optane technology, but it hasn’t really gained traction or fulfilled the promises that it made for transforming computing. Hewlett Packard Enterprise, as Soltis mentioned, is still doing research into memristors with tis Gen-Z protocol that is a derivative of its work on The Machine. But, like commercial nuclear fusion, it always seems just a few years away.
In any event, the architects designing the next generation of supercomputers to run traditional simulating and modeling workloads – in addition to the new data-intensive workloads that leverage new deep learning techniques (what is commonly called AI today) – are looking for fresh approaches to tackling the age-old computer science problem of keeping fast CPUs fed with data. And that has led them to Soltis and the single-level storage approach he was instrumental in developing so long ago for the System/38.
“The bottom line is the design they’re looking at is single-level storage,” Soltis said. “That didn’t come as a total surprise to me, primarily because of the benefit of single-level storage. I was just surprised that it took something like 40 years before the rest of the world sort of caught on to what this capability was.”
RELATED STORIES
Single-Level Store Redux In New Power-Flash Hybrids
The AS/400 At 28: A HENRY, Not A DINK
great interview with Dr. Frank. thanks
single level store has drawbacks. A program can only work with 16M chunks of memory. Which means strings have that max size. Which complicates how an RPG program loads a stream of JSON formatted data. ILE and PASE are two separate worlds on the IBM i. That complicates and limits how an RPG program can incorporate Linux open source code. If IBM i did not have single level store, using memory mapped files instead, would PASE have to even exist?
If you are processing 16m of JSON you are doing it wrong anyway. PASE on the other hand…
https://www.youtube.com/watch?v=MQg_1_v38Zk
HotOS 2021 — https://sigops.org/s/conferences/hoto…
“The Aurora Operating System: Revisiting the Single Level Store”
Emil Tsalapatis, Kenneth Ryan Hancock, Tavian Barnes, Ali Mashtizadeh (University of Waterloo)