The road to Zettalinux [LWN.net]

The road to Zettalinux

Posted Sep 16, 2022 14:16 UTC (Fri) by atnot (guest, #124910)
In reply to: The road to Zettalinux by ianmcc
Parent article: The road to Zettalinux

I don't think memory with more than 2^64 locations will exist any time soon either. But that does not mean that 2^64 bits is enough.

The major improvement between 32 and 64 bit was not just allowing more memory to be addressed, but that addresses ceased being a scarce resource. This means that today, you can do things like mmap nearly unlimited files regardless of their size, with ASLR, store additional metadata in your pointers and *still* have more than enough bits to address everything you could ever want without even having to think about fragmentation.

That's where the true crunch will be felt IMO, and it's going to be far sooner than the availability of hypothetical 2^64 or even 2^48 byte memory sticks. Terrabyte file sizes are already common, exabytes are a meaningful unit and things like nvmeof or cxl are likely set to allow a single computer to access far more storage than it's ever been able to. A world where virtual addresses might become scarce again is definitely closer than one would think.

to post comments

The road to Zettalinux

Posted Sep 16, 2022 15:22 UTC (Fri) by linuxrocks123 (subscriber, #34648) [Link] (6 responses)

Is that a problem worth solving, though? Do we really want every pointer to be four times as big as it needs to be just so someone can mmap a whole hard drive? I don't think so.

"Four times as big" because x32 demonstrates that, if we try to squeeze, 32 bits is still enough for a userspace address space. The fact that x32 didn't take off demonstrates that it's not worth the effort to bother saving that memory, but I'd still rather not see us make pointers even fatter.

The road to Zettalinux

Posted Sep 16, 2022 16:03 UTC (Fri) by epa (subscriber, #39769) [Link] (5 responses)

Perhaps 'near' and 'far' pointers will make a comeback?

The road to Zettalinux

Posted Sep 16, 2022 18:41 UTC (Fri) by Wol (subscriber, #4433) [Link] (4 responses)

Segmented memory? I was thinking that ...

Cheers,
Wol

The road to Zettalinux

Posted Sep 18, 2022 9:43 UTC (Sun) by jengelh (subscriber, #33263) [Link] (3 responses)

Segmented memory sucked. You had two 16-bit registers, but rather than allowing to reach 32 bits worth of address space, the x86 implementation of it only gave you 20 bits. What a waste. Wouldn't want to repeat that.

The road to Zettalinux

Posted Sep 18, 2022 10:45 UTC (Sun) by Wol (subscriber, #4433) [Link]

That was Intel. I used 50-series which also had segmented memory, and while I know far less about the silicon internals, I gather it worked very well.

It didn't migrate very well to Intel, and quite possibly because their segmentation was (compared to 50-series) broken.

I know it was used for security, for separating the OS from user-space, and from separating users/processes from each other.

Cheers,
Wol

The road to Zettalinux

Posted Sep 19, 2022 12:51 UTC (Mon) by eru (subscriber, #2753) [Link] (1 responses)

You are thinking of real-mode segmentation in 16-bit x86. In 386 and later protected mode, segments can be up to 4G, you have two additional segment registers (FS and GS), and addressing happens via a descriptor table, where you can set protections and the size of the segment, getting an exception if a pointer accesses outside it. I have worked with an inhouse OS that actually used these features.

The road to Zettalinux

Posted Nov 20, 2022 20:43 UTC (Sun) by nix (subscriber, #2304) [Link]

386 and later protected mode, segments can be up to 4G, you have two additional segment registers (FS and GS), and addressing happens via a descriptor table, where you can set protections and the size of the segment, getting an exception if a pointer accesses outside it. I have worked with an inhouse OS that actually used these features.

This was true on 386 and later in real mode too: you just had to set things up right in protected mode first (basically setting up the selector bounds right before transitioning back). Of course, this 'unreal mode' wasn't too useful, given that unless you were stuck in DOS you might as well just use protected mode, but it was there. There were really very few differences between real and protected mode on the 386: real mode was protected mode in a very, very thin disguise. You could use the full register file (%eax et al) and everything. Long mode on x86-64, now, *that's* different.

The road to Zettalinux

Posted Sep 16, 2022 22:59 UTC (Fri) by bartoc (guest, #124262) [Link] (1 responses)

Similar to the rationale for why ipv6 picked 128bit addresses instead of like 48bit.

The road to Zettalinux

Posted Sep 17, 2022 6:56 UTC (Sat) by gdt (guest, #6284) [Link]

IPv6 was designed for 80 bits for network addressing (with 16 bits expected to be used for addressing within a site) and 48 bits for the autoconfiguration feature (basically, the ethernet MAC address, the longest station address of the era). More than a third of the network addressing was expected to be used for better network aggregation than IPv4; that is, to trade off the number of addressable networks for improved stability and small global routing table sizes.

In practice, much of that design had to be altered in practice.

Starting with IEEE pointing out their next-generation station addressing for their future ethernet follow-on protocol. This 'EUI' used 64 bits for station addressing. So barely was the design finalised before the intended addressing had to be altered to the (64, 64) split between network and station addressing which we have now.

I can't think of a single ISP which has used IPv6's in-service network prefix change feature, which was meant to allow even huge ISPs to advertise just one prefix. So plans for route aggregation haven't been as successful as hoped.

To reduce configuration error, routers moved away from being able to identify single bits in addresses (eg, moving from the 'subnet mask' notation to the 'prefix length' notation). This means that it's hard for sites to use their subnetting allocation to carry meaning (such as a particular bit-pattern meaning "no egress"). Whereas it's still possible to pick out selected bits in CPU's virtual addresses.