On top of that, it wasn't uncommon to connect those tiny LPARs to shared storage RAID arrays with hundreds of machines on the same array, and allocate them a tiny chunk of two or three disks, and deal with all the contention there.
During that time period, I worked for a hot second at EMC, and was always fascinated to see these types of configurations - where it was very clear you could get MUCH better price/performance by buying Linux pizza boxes and connecting them to local storage - but back in those days it was not acceptable at big companies to do that.
On the flip side, those pSeries and high-end Sun boxes screamed when they were optimized for high I/O and high performance workloads. 15 years ago, and you'd see clusters of these pSeries boxes processing 400k-500k writes/second and up on Oracle and DB2. Truly impressive stuff for 2000 & 2001.
To be fair it can be due to a crappy cvs port or related to something that cvs do that does not work well on the non-unixy memmory mapped io model on AIX.
That way you'd have reduced load and therefore a snappier system.
CVS is a version control system. We kept (a copy of ) the source in the laptop.
The actual system we developed was running in machines guarded by hordes of sysadmins grumped up to the proper level, possibly even employed by IBM.
The linux laptop was then connected to a well used wan-connection in another location, and we tunneled to it using ssh, instead of just accessing it on the 100 mbit lan, and sent out an apologetic email notifying the developers that things would be really slow until we had sorted things out with the AIX systems. ( They had to be moved to another location.)
We found to our surprise that the throughput dramatically improved and checkout times where reduced to almost nothing compared to the AIX machine it usually ran on.
Now, maybe CVS is an exceptionally bad workload for AIX or something, but I doubt that it's an uncommon workload. AIX might possibly scale to more CPUs efficiently, but it was a clear disappointment nevertheless.