[Info-vax] OpenVMS, and Memory and Storage Addressing (was: Re: VMS Software needs to port VAX DIBOL to OpenVMS X86 platform

[Stephen Hoffman]

On 2020-12-26 18:00:03 +0000, <kemain.nospam at gmail.com> said:

>> -----Original Message-----
>> From: Info-vax <info-vax-bounces at rbnsn.com> On Behalf Of Arne Vajhøj 
>> via Info-vax
>> Sent: December-24-20 2:38 PM
>> 
>> So they [IBM POWER] can do 2 PB and x86-64 can only do 256 TB. ...
>> 
> 
> The market is changing very rapidly.
> 
> Seagate and Western Digital now offer 18TB disks.  (google "18TB disk")
> 
> Large enterprise class VMware servers hosting large numbers of VM's are 
> configured today with 1-2TB memory per server.
> 
> How many would have predicted these capabilities even 2 or 3 years ago?
> 
> Now, fast forward 5 years - its not hard to see what appear to be far 
> away limits being pushed.


Currently-available Intel x86-64 processors support 57-bit physical 
addressing. That permits 128 PiB of physical memory.

https://software.intel.com/sites/default/files/managed/2b/80/5-level_paging_white_paper.pdf 


Linux added support for that, and likely too most other virtual 
machines either have or are adding 57-bit support. I expect that VSI is 
aware of Intel 57-bit physical addressing support, as well.

Interestingly for the "just add more memory" approach, particularly as 
the I/O speeds increase, the need for larger physical memory can be 
lessened—benchmarks from one recent commercially-available Arm-based 
system are showing that less can RAM work well, when the memory and I/O 
paths are reworked. Big memory is a good cache when main storage access 
is HDD-speed glacial. When main storage is NVMe speeds, paging and 
swapping can (again) be a viable trade-off. And with byte-addressable 
non-volatile storage becoming available, these same server design 
trade-offs trade-offs shift again.

It'll be a while before we're using 18 TB HDDs with OpenVMS, though. 
That's all dependent on the 64-bit I/O system updates (queued for the 
unreleased V8.5, prolly arriving in production at V9.2), on a new file 
system, and/or on app updates.

And as for big memory and big storage and OpenVMS as most will probably 
see it, the VM can present a four-level page table to the OpenVMS 
guest, as well as the 2 TiB and smaller disks expected by existing apps 
and the ODS-2 and ODS-5 file systems. Those folks that need or want 
native boot will be picking their configurations to operate within 
whatever limits are then applicable to OpenVMS—or finding a person or a 
vendor to configure and test their servers for them.

Most (all?) vendors with 64-bit are running a subset of bits for 
physical addressing and the unused or unimplemented address bits all 0 
or all 1 bits, which means the servers will be available as the demand 
warrants. And I can do pretty well with SSDs and less than 48 bits of 
memory for the apps that I'm dealing with and know about, and NVMe 
storage will speed that. Folks that are stuck by 48- or 50-bit 
addressing, or planning for OpenVMS supercomputer-scale configurations, 
have a chat with VSI. And have a look at your I/O speeds and feeds and 
related app designs, too.

-- 
Pure Personal Opinion | HoffmanLabs LLC