5 ms·

Something that's always baffled me: why don't CPUs have a "save ALL state" and "restore ALL state" instructions? Why does every new set of CPU registers seem to

Something that's always baffled me: why don't CPUs have a "save ALL state" and "restore ALL state" instructions? Why does every new set of CPU registers seem to require an OS update to save them on context switches?

JoshTriplett 10y ago
They do, now. On current Intel CPUs, you can use xsave and xrstor to save and load the complete state, including all new state information. Ring 0 code can ask the CPU for the size of that state (via CPUID leaf 0xd), and allocate the appropriate amount of space per task.
- wfunction 10y ago
  Oh wow. When did this change? I vaguely seem to remember that as recently as Windows 7 (or was it 8.0?) there was trouble with AVX2 or something, but I can't find the info anywhere at the moment.
  - JoshTriplett 10y ago
    An OS can still use xsave incorrectly, such as by hardcoding the expected size rather than detecting it at runtime, or by getting some aspect of the CPUID leaf 0xd enumeration wrong. I wouldn't find it surprising if an initial implementation got one of the details wrong, resulting in a bug that wouldn't manifest until the next time the xsave layout changed.
    - amelius 10y ago
      The CPU designers could have protected against this by randomly fluctuating the size of the xsave'd data.
      - monocasa 10y ago
        At the cost of extra bandwidth and interrupt latency.
        amelius 10y ago
        Yes, but only marginally if they changed the size only 1 out of 1000 times.
        spdionis 10y ago
        Adding complexity (that could result in bugs) in the hope to prevent bugs by bad usage of the interface is usually a bad idea.
  - MaulingMonkey 10y ago
    Perhaps you're thinking of this debugger issue? https://randomascii.wordpress.com/2013/03/11/should-this-windows-7-bug-be-fixed/ https://randomascii.wordpress.com/2013/03/11/should-this-win...
    - wfunction 10y ago
      Ah yes, good find, I believe this was one of them! I don't remember if there were more though, there might have been.
geocar 10y ago
When the number of state variables gets bigger, that buffer needs to get bigger. Need some cooperation from the operating system to increase the size of the buffers, that's all.
- wfunction 10y ago
  That doesn't mean the CPU can't report the size necessary using another instruction though. There's no need for the OS code to change.
colanderman 10y ago
After some careful reading of the linked bug report, apparently saving the direction flag wasn't the issue. Rather, clearing it upon entering a signal handler was the issue.
spc476 10y ago
The more state you save, the larger the latency in handling the interrupt. And the amount of state in modern CPUs can be quite large indeed.
- wfunction 10y ago
  Any idea how much it is? (just as a guess, I'd guess like maybe 8 KiB?)
  - haimez 10y ago
    Show your work.
    - wfunction 10y ago
      I don't remember how many there were for AVX, but let's say there are 8 512-bit registers (4 KiB)? and then equivalent in other kinds of registers, so 8 KiB. Just an order-of-magnitude estimate, nothing I expect to be too accurate.
      - haimez 10y ago
        I'm also not an expert, but I think the bigger cost here is memory latency. Size correlates to, but scales differently than the switching cost of registers because it's zero sum. A register saved is a register waited on, twice. There's also the cost of decoding and executing the instructions to store / restore the register values on both ends.
        wfunction 10y ago
        I don't get it, you have to save and restore all the state on context switches either way. The only question is whether you're doing it with a generic instruction or through some other more specialized instructions. It's not a question of whether they should be saved and restored at all. That said, I'm confused why you replied to my comment above, since it's totally off-topic. This thread chain was asking how much state exists; maybe you were trying to reply to another thread?

JoshTriplett 10y ago

They do, now. On current Intel CPUs, you can use xsave and xrstor to save and load the complete state, including all new state information. Ring 0 code can ask the CPU for the size of that state (via CPUID leaf 0xd), and allocate the appropriate amount of space per task.

wfunction 10y ago
Oh wow. When did this change? I vaguely seem to remember that as recently as Windows 7 (or was it 8.0?) there was trouble with AVX2 or something, but I can't find the info anywhere at the moment.
- JoshTriplett 10y ago
  An OS can still use xsave incorrectly, such as by hardcoding the expected size rather than detecting it at runtime, or by getting some aspect of the CPUID leaf 0xd enumeration wrong. I wouldn't find it surprising if an initial implementation got one of the details wrong, resulting in a bug that wouldn't manifest until the next time the xsave layout changed.
  - amelius 10y ago
    The CPU designers could have protected against this by randomly fluctuating the size of the xsave'd data.
    - monocasa 10y ago
      At the cost of extra bandwidth and interrupt latency.
      - amelius 10y ago
        Yes, but only marginally if they changed the size only 1 out of 1000 times.
        spdionis 10y ago
        Adding complexity (that could result in bugs) in the hope to prevent bugs by bad usage of the interface is usually a bad idea.
- MaulingMonkey 10y ago
  Perhaps you're thinking of this debugger issue? https://randomascii.wordpress.com/2013/03/11/should-this-windows-7-bug-be-fixed/ https://randomascii.wordpress.com/2013/03/11/should-this-win...
  - wfunction 10y ago
    Ah yes, good find, I believe this was one of them! I don't remember if there were more though, there might have been.

geocar 10y ago

When the number of state variables gets bigger, that buffer needs to get bigger. Need some cooperation from the operating system to increase the size of the buffers, that's all.

wfunction 10y ago
That doesn't mean the CPU can't report the size necessary using another instruction though. There's no need for the OS code to change.

colanderman 10y ago

After some careful reading of the linked bug report, apparently saving the direction flag wasn't the issue. Rather, clearing it upon entering a signal handler was the issue.

spc476 10y ago

The more state you save, the larger the latency in handling the interrupt. And the amount of state in modern CPUs can be quite large indeed.

wfunction 10y ago
Any idea how much it is? (just as a guess, I'd guess like maybe 8 KiB?)
- haimez 10y ago
  Show your work.
  - wfunction 10y ago
    I don't remember how many there were for AVX, but let's say there are 8 512-bit registers (4 KiB)? and then equivalent in other kinds of registers, so 8 KiB. Just an order-of-magnitude estimate, nothing I expect to be too accurate.
    - haimez 10y ago
      I'm also not an expert, but I think the bigger cost here is memory latency. Size correlates to, but scales differently than the switching cost of registers because it's zero sum. A register saved is a register waited on, twice. There's also the cost of decoding and executing the instructions to store / restore the register values on both ends.
      - wfunction 10y ago
        I don't get it, you have to save and restore all the state on context switches either way. The only question is whether you're doing it with a generic instruction or through some other more specialized instructions. It's not a question of whether they should be saved and restored at all. That said, I'm confused why you replied to my comment above, since it's totally off-topic. This thread chain was asking how much state exists; maybe you were trying to reply to another thread?