6 ms·

What's the "cost" of registers on an x86-64 chip? How hard would it be to introduce 10 more general purpose registers? Ones that are used by the kernel, say, an

• vardump 10y ago
  Because you say kernel, I'm assuming you mean ability to switch a set of registers instead of pushing them on the stack when servicing an interrupt request. Unfortunately you can't get away with just one set of spare registers on x86 interrupt handling. Interrupt can be interrupted by another interrupt. So practically they have to save registers anyways. Unless there'd be one set for each level... So those "10 extra registers" would be practically useless. Having written kernel device driver interrupt handlers, I can also say CPU time is not spent saving and restoring registers, but waiting for glacially slow PCI-e MMIO register loads and stores (don't have exact figures at hand, but I remember one access can take 300-800 nanoseconds, that's thousands of CPU clock cycles). During one such fetch you might be able to store and restore registers tens, if not hundreds of times. X86 interrupt handling is a bit like stopping a freight train to pick up a single letter. However, that kind of feature can be very useful on a microcontroller to help lowering interrupt handling latency.
  • Dylan16807 10y ago
    > Interrupt can be interrupted by another interrupt. So practically they have to save registers anyways. Only when an interrupt actually does get interrupted. You could make the common case faster. Not that it matters if PCI-e is the bottleneck.
    • vardump 10y ago
      Then all interrupts need to be prepared for it and check for it anyways. Crucially, the code path that does the check might also get interrupted, even multiple times. No synchronization is possible, and even if it was, it'd be slower than simply saving the registers. So what do you suggest could be done?
      • Dylan16807 10y ago
        It doesn't matter if that code path gets interrupted. There's no need to synchronize anything. If interrupt A sees that the extra registers are idle, and then gets interrupted, that's okay. By the time the inner interrupt returns, even if the inner interrupt used them, they will be put back to idle, and A can safely switch to them. Everything else works the same as current hardware. There's the cost of a branch, but you could remove that by making it a hardware feature. It's a branch that should predict well though.
  • CyberDildonics 10y ago
    Isn't a cache miss around 100 nanoseconds? This sounds like memory latency without all the out of order execution and other modern CPU features.
    • vardump 10y ago
      Nothing to do with (local) DRAM, everything to do with PCI-e bus. Reading and writing to memory mapped I/O registers is how you send commands to peripherals, read their status, etc. These registers are not really memory at all, but representation on various logic states on the peripheral. So what you write is often not what you read back. Note that I/O memory mapping has nothing to do with usermode memory mapping.
• unsigner 10y ago
  x86-64 chips have hundreds of general purpose registers; google "register renaming"
  • vardump 10y ago
    Hardly relevant in (obvious) interrupt service routine context. These registers you're talking about are only used for reordering instruction stream to avoid stalls. Nice for general performance, but useless when servicing interrupts.
• kqr 10y ago
  As far as I understand it, the x86 uses many more registers than you think "under the hood", and it's exposing just a few "virtual registers" that are mapped to any of the underlying ones. So what you're thinking of is already done to an extent, except the at the kernel-level it's invisible. (Exposing more virtual registers have two main costs, then: you lose backwards compatibility for all programs that use the extended register set, and to back them up with the same technique you need several more real registers.)
• exDM69 10y ago
  There are about 180 registers in the register file already. There are only names for 16 or so registers, the CPU internally does renaming for them. It would be possible to specify an API that leaves a part of the named registers reserved for kernel, but that wouldn't really help. When an interrupt or system call happens, all the registers get pushed to the stack. The stack is typically in L1 cache (and subject to various CPU optimizations), so it's really fast to push the 16*64 bit registers to the stack. System calls, interrupts and context switches are "slow" not because they have trivial overhead like pushing registers. What's really consuming the time is secondary effects like TLB flushes, changes to the page tables, polluting the branch predictor, etc. It takes a very long time for the CPU to "warm up" again after a context switch.
  • xxs 10y ago
    System calls are mode switch that's way faster than a context (i.e. process) switch. The latter virtually always has cold caches. I've made the remark because it's fairly common to mistake mode and context switches.
    • exDM69 10y ago
      Yes, and the x86-64 has a fast SYSCALL instruction.
      • monocasa 10y ago
        Fast being in the thousands of cycles last time I checked.
        • the_mitsuhiko 10y ago
          The whole syscall maybe but certainly not the method of invoking it.
        • deleted 10y ago
          [deleted]
  • 10y ago