Linux's multiprocessor support was ...lackluster at best... prior to IBM contributing all the Sequent (Dynix) derived multiprocessing stuff. Hyperthreading/Multicore started to get "normal" even in consumer systems only a couple years later, so that injection was pretty critical.
Likewise, a lot of Linux's development inertia and cultural acceptance came from being a cheap and consistent alternative to screwing around with the profusion of expensive and mutually incompatible proprietary Unixes in the Server and (as clusters co-evolved) HPC market.
On the broader issue, the tension here is that IBM thinks the value proposition of RHEL is "Supported" and (I suspect) almost everyone else regards the value proposition of RHEL as "standard base." I think it's more likely that the "standard base" for srs bsns Linux in the markets where RHEL is the standard would rebase than IBM having any success trying to squeeze customers, and if that happens the value of "Owning RHEL" suddenly shrinks dramatically. Honestly, all it would take is the RHEL-likes like Alma and Rocky to agree on a coordination mechanism that isn't matching RHEL - could be through a major public interest like CERN, could be through an existing commercial interest like coordinating with Oracle (ew), could be via one of the several entities that does commercial support for RHEL-likes ... there are options.
Oracle being a gigantic litigious parasite on society is a broader issue, and I understand regarding commercial RHEL-likes as more of a problem, but even they have been funding a lot of backport-to-LTS type work.
>Linux's multiprocessor support was ...lackluster at best... prior to IBM contributing all the Sequent (Dynix) derived multiprocessing stuff. Hyperthreading/Multicore started to get "normal" even in consumer systems only a couple years later, so that injection was pretty critical.
It was certainly needed over time but capabilities from things like RCU out of Sequent weren't that important in the 2000 timeframe. And a lot of IBM's contributions didn't come online until the v4 kernel.
None of this is to minimize IBM's contributions to Linux over time but I'd argue pretty strongly that IBM's endorsement of Linux for enterprises in January 2000 is what really moved the needle in the short run.
Here's what one of the people most directly involved told me a few years ago:
"By the late 90s, it was clear that Linux was becoming more and more important. And we formed a major task force to see to what extent IBM should embrace Linux and this happened in 1999. And the task force came back and said, we absolutely should embrace Linux, that it was going to be an incredibly important part of computing, that we should embrace Linux across all of IBM's offerings. And that IBM should become a major supporter of Linux.
"And I still remember very well in December of ‘99, I called Sam Palmisano, the head of IBM Systems Group. And I said, Sam, the task force recommends that we should embrace Linux. And Sam said, okay, Irving, we will do that. But you have to now come over and run an IBM Linux initiative. And I said to Sam, okay, we were pretty much done with our internet strategy. So I was no longer needed to run the Internet division And I said to Sam, when do you want to announce it? And Sam said, how about now? And I said Sam. It's the Christmas holidays. Maybe we should wait until the new year. And in the second week of January of 2000, we made a major announcement saying that IBM would embrace Linux across all of these offerings. And in fact, later that month in January of 2000, I gave a keynote at LinuxWorld, which was taking place in the Javits Center in New York City, about IBM’s Linux initiative.
I was mixing up where the big multiprocessor changes that went into the 2.5 series in that 2000-2005 era came from.
I was thinking of the the basic kernel preemption stuff and sched_setaffinity syscall + userspace plumbing like taskset that is _extremely_ consequential on little multicore/SMT machines, but the prominent name on a lot of that was Robert Love and he was at MontaVista at the time.
The Dynix parts that arrived via IBM were, as you say, mostly NUMA and RCU stuff based on Paul McKenney's work, which also went in in the same major overhaul during the 2.5 series but weren't quite so immediately consequential to smaller systems.
I hadn't heard that anecdote, but that is a neat tale of IBM using their gravitas at the time to legitimize Linux.
SGI also did a lot of scalability work in that time frame, as part of their migration from MIPS+Irix to Itanium+Linux. In the end they got Linux working on IIRC up to 4096 processors.
Linux's multiprocessor support was ...lackluster at best... prior to IBM contributing all the Sequent (Dynix) derived multiprocessing stuff. Hyperthreading/Multicore started to get "normal" even in consumer systems only a couple years later, so that injection was pretty critical.
Likewise, a lot of Linux's development inertia and cultural acceptance came from being a cheap and consistent alternative to screwing around with the profusion of expensive and mutually incompatible proprietary Unixes in the Server and (as clusters co-evolved) HPC market.
On the broader issue, the tension here is that IBM thinks the value proposition of RHEL is "Supported" and (I suspect) almost everyone else regards the value proposition of RHEL as "standard base." I think it's more likely that the "standard base" for srs bsns Linux in the markets where RHEL is the standard would rebase than IBM having any success trying to squeeze customers, and if that happens the value of "Owning RHEL" suddenly shrinks dramatically. Honestly, all it would take is the RHEL-likes like Alma and Rocky to agree on a coordination mechanism that isn't matching RHEL - could be through a major public interest like CERN, could be through an existing commercial interest like coordinating with Oracle (ew), could be via one of the several entities that does commercial support for RHEL-likes ... there are options.
Oracle being a gigantic litigious parasite on society is a broader issue, and I understand regarding commercial RHEL-likes as more of a problem, but even they have been funding a lot of backport-to-LTS type work.