Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The road to Zettalinux

lwn.net

Post reply on HN
Print view View original

61–70 of 199 posts

Re: The road to Zettalinux

#61

Post by wongarsu »

gwbas1c wrote: post #41

> Matthew Wilcox took the stage to make the point that 64 bits may turn out to be too few — and sooner than we think Let's think critically for a moment. I grew up in the 1980s and 1990s, when we all craved more and more powerful computers. I even remember the years when each generation of video games was marketed as 8-bit, 16-bit, 32-bit, ect. BUT: We're hitting a point where, for what we use computers for, they're…

We are talking about the OS kernel that supports 4096 CPU cores. The companies who pay their engineers to do linux kernel development tend to be the same ones that have absurd needs.

Re: The road to Zettalinux

#62

Post by mikepurvis »

gwbas1c wrote: post #41

> Matthew Wilcox took the stage to make the point that 64 bits may turn out to be too few — and sooner than we think Let's think critically for a moment. I grew up in the 1980s and 1990s, when we all craved more and more powerful computers. I even remember the years when each generation of video games was marketed as 8-bit, 16-bit, 32-bit, ect. BUT: We're hitting a point where, for what we use computers for, they're…

IMO there's an important distinction to be made between high-bit addressing and high-bit computing.

Like, no one has enough memory to need more than 64 bits for addressing, and that is likely to remain the case for the foreseeable future. However, 128- and 256-bit values are commonly used in domains like graphics, audio, and so-on, where you need to apply long chains of transformations and filters, but retain as much of the underlying dynamic range as possible.

Re: The road to Zettalinux

#63

Post by shadowofneptune »

dragontamer wrote: post #34
jmillikin wrote: post #18

The section about 128-bit pointers being necessary for expanded memory sizes is unconvincing -- 64 bits provides 16 EiB (16 x 1024 x 1024 x 1024 x 1 GiB), which is the sort of address space you might need for byte-level addressing of a warehouse full of high-density HDDs. Memory sizes don't grow like they used to, and it's difficult to imagine what kind of new physics would let someone fit that many bytes into a mach…

> it's difficult to imagine what kind of new physics would let someone fit that many bytes into a machine that's practical to control with a single Linux kernel instance. I nominally agree with most of your post. But I should note that modern systems seem to be moving towards a "one pointer space" for the entire cluster. For example, 8 GPUs + 2 CPUs would share the same virtual memory space (GPU#1 may take one slice,…

Even so, existing ISAs could address more memory using segmentation. AMD64 has a variant of long mode where the segment registers are re-enabled. For the special programs that need such a large space, far pointers wouldn't be that complicating.

Re: The road to Zettalinux

#64

Post by anotherhue »

jmillikin wrote: post #18

The section about 128-bit pointers being necessary for expanded memory sizes is unconvincing -- 64 bits provides 16 EiB (16 x 1024 x 1024 x 1024 x 1 GiB), which is the sort of address space you might need for byte-level addressing of a warehouse full of high-density HDDs. Memory sizes don't grow like they used to, and it's difficult to imagine what kind of new physics would let someone fit that many bytes into a mach…

FYI Such memory tagging has a rich history https://en.wikipedia.org/wiki/Tagged_architecture

Re: The road to Zettalinux

#65

Post by cestith »

yetihehe wrote: post #13
PaulHoule wrote: post #8

Earlier quoted context omitted.

C dates back to a time when the 8 bit byte didn’t have 100% market share.

Plus, it was a language to write systems, where "size of register on current machine" was a nice shortcut for "int", where registers could be anywhere from 8-32 bits, with 48 or 12 also a possibility.

I have a couple of 12-bit machines upstairs. There were also 36-bit systems once upon a time.

Re: The road to Zettalinux

#66

Post by fanf2 »

marktangotango wrote: post #27
rmorey wrote: post #19

this seems just a bit too early - so that probably means it’s exactly the right time!

I was wondering if this (128bit memory) are on the radar of any of the BSDs. Will they forever be stuck at 64bit?

CheriBSD might be the first unix-like with 128 bit pointers

Re: The road to Zettalinux

#67

Post by gwbas1c »

uluyol wrote: post #58
gwbas1c wrote: post #41

> Matthew Wilcox took the stage to make the point that 64 bits may turn out to be too few — and sooner than we think Let's think critically for a moment. I grew up in the 1980s and 1990s, when we all craved more and more powerful computers. I even remember the years when each generation of video games was marketed as 8-bit, 16-bit, 32-bit, ect. BUT: We're hitting a point where, for what we use computers for, they're…

Supercomputers? Rack-scale computing? See some of the work being done with RDMA and "far memory".

Yes... And do you need that in the same kernel that goes into your phone and your web server?

Re: The road to Zettalinux

#68

Post by dragontamer »

rwmj wrote: post #43
dragontamer wrote: post #34

Earlier quoted context omitted.

> it's difficult to imagine what kind of new physics would let someone fit that many bytes into a machine that's practical to control with a single Linux kernel instance. I nominally agree with most of your post. But I should note that modern systems seem to be moving towards a "one pointer space" for the entire cluster. For example, 8 GPUs + 2 CPUs would share the same virtual memory space (GPU#1 may take one slice,…

Distributed Shared Memory is a thing, but I'm not sure how widely it is used. I found that it gives you all the coordination problems of threads in symmetric multiprocessing but at a larger scale and with much slower synchronisation. https://en.wikipedia.org/wiki/Distributed_shared_memory

https://en.wikipedia.org/wiki/Remote_direct_memory_access

Again, I'm not a supercomputer programmer. But the whitepapers often discuss RDMA.

From my imagination, it sounds like any other "mmap". You, the programmer, just remembers that the mmap'd region is slower (since it is read/write to a Disk, rather than to RAM). Otherwise, you treat it "like RAM" from a programming perspective entirely for convenience sake.

As long as you know my_mmap_region->next = foobar(); is a slow I/O operation pretending to be memory, you're fine.

---------

Modern systems are converging upon this "single address space" programming model. PCIe 3.0 implements atomic operations and memory barriers, CXL is going to add cache-coherence over a remote / I/O interface. This means that all your memory_barriers / atomics / synchronization can be atomic-operations, and the OS will automatically translate these memory commands into the proper I/O level atomics/barriers to ensure proper synchronization.

This is all very new, only within the past few years. But I think its one of the most exciting things about modern computer design.

Yes, its slow. But its consistent and accurately modeled by all elements in the chain. Atomic-compare-and-swap over RDMA can allow for cache-coherent communications and synchronization over Ethernet, over GPUs, over CPUs, and any other accelerators sharing the same 64-bit memory space. Maybe not quite today, but soon.

This technology already exists for PCIe 3.0 CPU+GPUs synchronization from 8 years ago (Shared Virtual Memory). Its exciting to see it extend out into more I/O devices.

Re: The road to Zettalinux

#69

Post by travisgriggs »

jmillikin wrote: post #18

The section about 128-bit pointers being necessary for expanded memory sizes is unconvincing -- 64 bits provides 16 EiB (16 x 1024 x 1024 x 1024 x 1 GiB), which is the sort of address space you might need for byte-level addressing of a warehouse full of high-density HDDs. Memory sizes don't grow like they used to, and it's difficult to imagine what kind of new physics would let someone fit that many bytes into a mach…

> (comedy option: 32-bit int, 128-bit long, and 64-bit `unsigned middle`)

Or rather than keep moving the long goalpost, keep long at u64/i64 and add prolong(ed) for 128. Or we could keep long as the “nominal” register value, and introduce “short long” for 64. So many options.

Re: The road to Zettalinux

#70

Post by zasdffaa »

Sounds nuts. Does anyone know how much power a 32GB DIMM draws? How much would a fully populated 64-bit address space therefore pull?

Edit, if a 4GB (32-bits used) DRAMM pulls 1 watt, the rest of the memory space is 32 bit = 4E9 so your memory is pulling ~4Gwatts alone. That's not supportable, given the other electronics needed to go around it.

Post reply on HN