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

Lots of bugs in 32-bit x86 Linux entry code

lwn.net

Post reply on HN
Print view View original

81–90 of 110 posts

Re: Lots of bugs in 32-bit x86 Linux entry code

#81

Post by nwmcsween »

wahern wrote: post #41
jdsully wrote: post #30

Earlier quoted context omitted.

At the time 1GB was a ton of memory and few applications would use anywhere near that. A 64-bit kernel took on fairly quickly but actually compiling 64-bit applications took a lot longer. Consensus at the time was the memory overhead of larger pointers outweighed the benefits of extra registers.

> Consensus at the time I wouldn't call it consensus, just a persistent claim by a large fraction of developers. They finally got to prove their claims with x32 ABI, which was ILP32 in amd64 mode, including the additional registers. Few if any people used it, nor did it show better performance in practice. Regarding 64-bit support: by the time amd64 chips shipped people had been writing software for the 64-bit Alpha…

There were a few benchmarks IIRC where it showed a big improvement, the problem was that x32 ABI was horribly botched.

Re: Lots of bugs in 32-bit x86 Linux entry code

#82

Post by exikyut »

eru wrote: post #71
noobermin wrote: post #59

Earlier quoted context omitted.

Let's just hope we don't go through the same thing when we switch to 128-bit. We ought to learn from our mistakes when we do this whole thing again. And yes, before people flare me for this, don't pretend it isn't possible, recall that once upon a time 640K ought to be enough for anybody.

Why would we want to switch to 128 bit addresses? Do you know how much memory we can address with 64 bit? (64 bit for addresses was arguably a mistake. 48 bit word size would probably have been better, but doesn't sound as cool.) Having said that, 128 bit can make sense for certain calculations. So floating point calculations and GPUs support long registers for some of what they are doing. (And having said that, Goog…

The fact that you can put everything, ever into 128-bit means you can easily shove ten thousand 20-terabyte storage devices into a single 128-bit system's memory-mapped I/O space and still have 3 exabytes left over.

No more packet-switched serial storage I/O. You now have first-class ability to ask for any byte anywhere, really really really fast.

Because I/O request speed is now only limited by the the memory controller (which already goes at TB/sec in x86 hardware), a fast storage controller now has the opportunity to optimize and batch requests downstream to storage devices much much more efficiently. Because if the storage devices go at a certain speed but suddenly the addressing infrastructure is A LOT LOT faster, your optimization window just went through the roof and you can coordinate much more effectively.

I forget the exact architecture, but one of IBM's 128-bit boxen already does this. Various random bits of the hardware use MMIO as a first-class addressing strategy. The OS does the rough equivalent of `disk = mmap2(/dev/sda)` at bootup. Maybe this is a z series thing.

Re: Lots of bugs in 32-bit x86 Linux entry code

#83

Post by exikyut »

makomk wrote: post #44
heavyset_go wrote: post #4

Earlier quoted context omitted.

There were 32-bit netbooks being sold the last time I looked in 2015.

Unfortunately, upstream doesn't really notice if 32-bit x86 breaks. This isn't just a kernel problem; glibc managed to push out a release back in 2017 that broke memchr on 32-bit Atom in a way that tended to cause programs calling it to segfault. It turns out that amongst a few other things, including Python, the glibc build process itself relies on memchr working... I don't think they actually tested the code path i…

Of course it was tested [on the developers' x86_64 laptop(s)]!

Re: Lots of bugs in 32-bit x86 Linux entry code

#84

Post by sprash »

wahern wrote: post #41
jdsully wrote: post #30

Earlier quoted context omitted.

At the time 1GB was a ton of memory and few applications would use anywhere near that. A 64-bit kernel took on fairly quickly but actually compiling 64-bit applications took a lot longer. Consensus at the time was the memory overhead of larger pointers outweighed the benefits of extra registers.

> Consensus at the time I wouldn't call it consensus, just a persistent claim by a large fraction of developers. They finally got to prove their claims with x32 ABI, which was ILP32 in amd64 mode, including the additional registers. Few if any people used it, nor did it show better performance in practice. Regarding 64-bit support: by the time amd64 chips shipped people had been writing software for the 64-bit Alpha…

> Few if any people used it, nor did it show better performance in practice.

We use it for our specialized analysis framework. The real world performance gain is just shy of 30% which is impressive since all it took was a bunch of compiler flags.

Personally I think x32 is a vastly underused ABI. Every application that is unlikely to use more than 2GB should use it. It is literally free performance.

Re: Lots of bugs in 32-bit x86 Linux entry code

#85

Post by usr1106 »

eru wrote: post #71
noobermin wrote: post #59

Earlier quoted context omitted.

Let's just hope we don't go through the same thing when we switch to 128-bit. We ought to learn from our mistakes when we do this whole thing again. And yes, before people flare me for this, don't pretend it isn't possible, recall that once upon a time 640K ought to be enough for anybody.

Why would we want to switch to 128 bit addresses? Do you know how much memory we can address with 64 bit? (64 bit for addresses was arguably a mistake. 48 bit word size would probably have been better, but doesn't sound as cool.) Having said that, 128 bit can make sense for certain calculations. So floating point calculations and GPUs support long registers for some of what they are doing. (And having said that, Goog…

> Why would we want to switch to 128 bit addresses

Predicting the future is difficult. 30 years ago (I am old enough to remember) it was hard to imagine that every household would have 10s of devices connected to the internet. My university VAX for 16 concurrent student users had less memory than required to show the splash screen when today's phone boots.

So if in 30 years the computing paradigm has changed and we directly address memory over the internet? I must admit that in my imagination we have reached a point where growth will slow down. But I have learned that my imagination is not always good enough.

Re: Lots of bugs in 32-bit x86 Linux entry code

#86

Post by dependenttypes »

dexen wrote: post #78
eru wrote: post #71

Earlier quoted context omitted.

Why would we want to switch to 128 bit addresses? Do you know how much memory we can address with 64 bit? (64 bit for addresses was arguably a mistake. 48 bit word size would probably have been better, but doesn't sound as cool.) Having said that, 128 bit can make sense for certain calculations. So floating point calculations and GPUs support long registers for some of what they are doing. (And having said that, Goog…

"Why would we want to switch to 128 bit addresses?" - eru, 2019 I am gonna hold onto your quote, for enjoyment and giggles in 2032 :^)

This is only 13 years from now. I really doubt that people will need 16 EiB by then in a single processor for a single process. Plus by that point you will probably have moved to message passing between distributed systems or something.

Re: Lots of bugs in 32-bit x86 Linux entry code

#87

Post by boring_twenties »

tedunangst wrote: post #63
mehrdadn wrote: post #55

Earlier quoted context omitted.

What are you calling "disk" here? It's not every day that I see a machine with a disk slower than its network connection.

That might describe every rpi running off SD.

I dunno, not sure about the latest Pi models but the network performance was horrid on the earlier ones, like 20Mbits/sec tops.

Re: Lots of bugs in 32-bit x86 Linux entry code

#88

Post by mannschott »

exikyut wrote: post #82
eru wrote: post #71

Earlier quoted context omitted.

Why would we want to switch to 128 bit addresses? Do you know how much memory we can address with 64 bit? (64 bit for addresses was arguably a mistake. 48 bit word size would probably have been better, but doesn't sound as cool.) Having said that, 128 bit can make sense for certain calculations. So floating point calculations and GPUs support long registers for some of what they are doing. (And having said that, Goog…

The fact that you can put everything, ever into 128-bit means you can easily shove ten thousand 20-terabyte storage devices into a single 128-bit system's memory-mapped I/O space and still have 3 exabytes left over. No more packet-switched serial storage I/O. You now have first-class ability to ask for any byte anywhere, really really really fast. Because I/O request speed is now only limited by the the memory contro…

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

https://en.wikipedia.org/wiki/Single-level_store

Re: Lots of bugs in 32-bit x86 Linux entry code

#89

Post by anticensor »

exikyut wrote: post #82
eru wrote: post #71

Earlier quoted context omitted.

Why would we want to switch to 128 bit addresses? Do you know how much memory we can address with 64 bit? (64 bit for addresses was arguably a mistake. 48 bit word size would probably have been better, but doesn't sound as cool.) Having said that, 128 bit can make sense for certain calculations. So floating point calculations and GPUs support long registers for some of what they are doing. (And having said that, Goog…

The fact that you can put everything, ever into 128-bit means you can easily shove ten thousand 20-terabyte storage devices into a single 128-bit system's memory-mapped I/O space and still have 3 exabytes left over. No more packet-switched serial storage I/O. You now have first-class ability to ask for any byte anywhere, really really really fast. Because I/O request speed is now only limited by the the memory contro…

What about DMA over IPv6? Using a single 256-bit address, you would be able to address any byte in any IPv6-enabled computer directly.

Re: Lots of bugs in 32-bit x86 Linux entry code

#90

Post by eru »

dependenttypes wrote: post #86
dexen wrote: post #78

Earlier quoted context omitted.

"Why would we want to switch to 128 bit addresses?" - eru, 2019 I am gonna hold onto your quote, for enjoyment and giggles in 2032 :^)

This is only 13 years from now. I really doubt that people will need 16 EiB by then in a single processor for a single process. Plus by that point you will probably have moved to message passing between distributed systems or something.

My prediction is what we'll mostly see more of the same, with existing trends continuing.

Ie more mobile, and more parallelism on the server side.

But yeah, no 16 EiB on a single processor.

(Though we might see people memory map crazy amounts, without ever actually accessing all of them, of course.)

Post reply on HN