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

91–100 of 110 posts

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

#91

Post by trasz »

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…

Thing is, an “address” could be much more than an address. One example is the CHERI hardware capability stuff and its Arm counterpart, Morello: sizeof(void *) is 16 there.

And yeah, getting real world software, such as Postgres or Nginx, to work requires some fixes, but it’s really not that bad.

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

#92

Post by trasz »

derefr wrote: post #39
srgpqt wrote: post #37

Earlier quoted context omitted.

1GB is still a lot of memory. If anything, we've only learned to squander all available memory.

Go ahead and buffer 4k video streams to disk, I dare you :) There's a reason that even modern appliance platforms like Apple/Android TV need multiple GBs of memory, and it ain't bloat.

The irony is, on the other end the inverse is true - filesystem cache hit ratio on Netflix servers isn’t particularly high.

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

#93

Post by mavhc »

geofft wrote: post #60
yingw787 wrote: post #53

Earlier quoted context omitted.

I was able to upgrade from Lubuntu 16.04 to 18.04 for my 32bit IBM Thinkpad T42 using do_release_upgrade. It’s not downloadable on the website, but I think for 18.04 the build is still there.

I think they've stopped building them in 19.10. 18.04 is an LTS supported for 5 years, so users of i386-only CPUs are fine until 2023.

I have a load of 32bit laptops, "I'll put ChromiumOS on them", nope, that's not a thing any more. OK, err Linux? Apparently not. Could put Windows 10 on them I guess.

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

#94

Post by hvidgaard »

usr1106 wrote: post #85
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 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 d…

Direct addressing that way seems unfeasible, it would require a extending the IP stack to support direct addressing for it to work, and it already support 128 bit addresses. A far more feasible model is direct addressing through a unique IP, and we do not need a bigger address space for that.

That said, considering the current amounts of data Google holds, I could see the theoretical point about unique addressing every single byte they have. 64bit addressing only allow for a single order of magnitude of growth in that scenario.

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

#95

Post by hvidgaard »

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…

The calculations are off. 128 bit addressing allow for more than 3.40 x 10^38 addresses, and your storage example is 1.76 x 10^18 bits. That is, if we address the individual bits (we do not), we don't even have a name for the unit denoting that magnitude of space addressable left when using 128 bit addresses.

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

#96

Post by hvidgaard »

derefr wrote: post #39
srgpqt wrote: post #37

Earlier quoted context omitted.

1GB is still a lot of memory. If anything, we've only learned to squander all available memory.

Go ahead and buffer 4k video streams to disk, I dare you :) There's a reason that even modern appliance platforms like Apple/Android TV need multiple GBs of memory, and it ain't bloat.

If we aim high and say we need 50mbps of bitrate for 4k HDR, we still only need 6-7mb/s. So buffering 30 seconds is still less than 200mb.

It is entirely possible to make a modern system that use far less than they do today. If you're gaming it's a different beast, but for normal OS and programs it's certainly bloat.

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

#97

Post by bildung »

mavhc wrote: post #93
geofft wrote: post #60

Earlier quoted context omitted.

I think they've stopped building them in 19.10. 18.04 is an LTS supported for 5 years, so users of i386-only CPUs are fine until 2023.

I have a load of 32bit laptops, "I'll put ChromiumOS on them", nope, that's not a thing any more. OK, err Linux? Apparently not. Could put Windows 10 on them I guess.

You could try Debian, which is essentially Ubuntu minus some themes. I doubt Debian will drop i386 support soon (I just searched and couldn't find hints of an end of support of i386)

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

#98

Post by jagger27 »

imron wrote: post #73
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? How else are you going to have more than 16 exabytes of RAM?

Memory banking is the obvious and ancient solution. PAE is another.

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

#99

Post by benou »

robothread wrote: post #70
cptskippy wrote: post #16

Earlier quoted context omitted.

Completely off topic but... Althlon64 was a swift kick in the nuts for Intel, but AMD really didn't followup until Ryzen. I wonder if they're going to stick around and fight this time.

Well Intel wasn’t exactly sitting idle during the Athlon 64 era. It was just unfortunate that none of their plans worked out. NetBurst was a bust. IA-64 flopped too. Both were attempts to progress from the P6 architecture - which they felt had reached its limits. In the end, the market spoke, they want the P6. No one was willing to rewrite software (or even recompile). So back to the P6 in the form of the Pentium M f…

> which you would notice hasn’t improved much per core

Not sure which data you refer to? I just made a comparison on a single-threaded integer-heavy code between my old Core2 Duo and a Skylake, and just got x16 normalized perf improvement (from 2.5-cycles/byte to 0.15). Same code, same compiler.

So sure, progress have slowed down and they are adding more and more specialized stuff (AVX-512, AES-NI...) but still.

Edited for clarity.

Post reply on HN