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

71–80 of 110 posts

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

#71

Post by eru »

noobermin wrote: post #59
jdsully wrote: post #5

I remember being an early adopter of 64-bit Linux with my Athlon64 back in the day. Lots of stuff was broken and I got a lot of debate on whether it was any faster or worthwhile at all. It's really cool to see the technology curve go full circle.

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, Google figured out that they don't actually need all that precision when using GPUs for machine learning, and made TPUs with much smaller words.)

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

#72

Post by eru »

mehrdadn wrote: post #55
derefr wrote: post #39

Earlier quoted context omitted.

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.

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

An aside: that's often true in Google's data centres. So much, that someone wrote a system to sort-of swap out memory to other machines' RAM over the network (instead of to disk, which Google doesn't do in general).

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

#73

Post by imron »

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?

How else are you going to have more than 16 exabytes of RAM?

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

#74

Post by eru »

inetknght wrote: post #31
bonzini wrote: post #27

Earlier quoted context omitted.

You can certainly exploit Meltdown from a VM. The hypervisor tries hard to stay out of the way, and on a properly configured VM the vmexits should be few enough while running compute-bound code that microarchitectural side channels are very well exploitable.

For clarity, in this context I think @ vetrom was talking about emulation, not a virtual machine. A virtual machine makes use of the native instruction set (relying on the hardware) to create a machine within a machine and naturally can only create virtual machines of identical hardware capabilities (or a subset thereof). Emulation does all of that in software and could emulate even a completely different architectur…

Though to get fast emulation, you can re-use techniques from virtual machines (and vice versa).

Btw, emulation is how you can, in principle, run Linux on an 80286. (Normally you'd need a 80386 at least to get memory protection.)

Of course, Linux on the 80286 is gonna be even slower than Linux in your browser. (https://bellard.org/jslinux/)

Using the emulation idea you can go almost arbitrarily primitive. But the 286 is a nice target, because it was a sometimes requested feature in Linux's past.

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

#75

Post by jnwatson »

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…

Your modern Intel chip only has 48 addressable virtual address bits. The recent Ice Lake processors support 57 bits. I deal daily with Python processes that have "6.1t" in the "resident" column in top. Hitting the 48-bit 256 TiB limit isn't science fiction to me. I can already hit that with a moderate amount of effort (by memory mapping ~100 large kv-stores). It isn't that I need to do it, but I could imagine that someone does.

It is well and proper that Intel rounded up to 64 bits. It should serve us well for the next 40ish years, which is good enough for my professional lifetime at least.

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

#77

Post by eru »

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?

Exactly, you probably won't.

And I don't mean that in an absolute sense. People might very well get up to those orders of magnitude of RAM; but you are unlikely to have that amount of RAM available to a single processor.

The extra margin of the 64 bit might help with address space randomization, though.

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

#78

Post by dexen »

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?" - eru, 2019

I am gonna hold onto your quote, for enjoyment and giggles in 2032 :^)

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

#79

Post by nwmcsween »

koolba wrote: post #56
lazyguy2 wrote: post #52

Earlier quoted context omitted.

For several years I ran a 64bit kernel with 32bit userland. That way I was compatible with games and most other things without having to deal with increased memory usage and compatibility hacks.

There’s an even better target, x32, but sadly it never got much traction and is deprecated: https://en.wikipedia.org/wiki/X32_ABI The idea is to expose the 64-bit instruction set and registers, but keep memory and pointers per-process 32-bit as most apps use less than 4 GB of memory.

x32 failed due to the horribly botched ABI that was created.

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

#80

Post by eru »

jnwatson wrote: post #75
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…

Your modern Intel chip only has 48 addressable virtual address bits. The recent Ice Lake processors support 57 bits. I deal daily with Python processes that have "6.1t" in the "resident" column in top. Hitting the 48-bit 256 TiB limit isn't science fiction to me. I can already hit that with a moderate amount of effort (by memory mapping ~100 large kv-stores). It isn't that I need to do it, but I could imagine that so…

Yes, that's partially why I mentioned the 48 bits.

It's interesting that you mention hitting that with memory mapping in practice. That is a valid concern.

Post reply on HN