3 ms·

> The segment registers are almost useless these days, but saving and restoring them is very slow. Those are only saved/restored when switching between process

> The segment registers are almost useless these days, but saving and restoring them is very slow. Those are only saved/restored when switching between processes not between threads. Context switching when dealing with threads is typically done in software, not in hardware, precisely so that registers that are not used (like the segment registers) don't get needlessly saved & restored. Saving/restoring registers isn't even the expensive part of a context switch anyway. Switching address spaces, cache flushes/misses, etc... are all more expensive than saving/restoring registers.

bhouston 9y ago
> Those are only saved/restored when switching between processes not between threads. Context switching when dealing with threads is typically done in software, not in hardware, precisely so that registers that are not used (like the segment registers) don't get needlessly saved & restored. You are incorrect. Context switching is done for threads in HW. I think you are thinking of cooperative multi-threading (like pre-Windows 95, or nginx or node.js or V8) instead of true context-switching threading.
- dom0 9y ago
  > Context switching is done for threads in HW. Uhm, x86-64 can't switch between tasks/contexts in hardware.
- kllrnohj 9y ago
  All you need for preemptive multithreading is IRQ#0 to generate an interrupt. That's the entirety of it. Preemptive multiprocessing then needs paging and such to make isolated memory a thing as well, but still doesn't need HW context switching.
xorblurb 9y ago
Most registers including x86 segment registers need to be saved during context switches, regardless of its between threads or processes. E.g segment registers used for TLS. There are maybe optimisation for flat segments. > Context switching when dealing with threads is typically done in software, not in hardware I'm not sure any OS exists that does register saving in HW for switches between processes and in SW for switches between threads. Its especially doubtful for Linux, given it does not really have a very strong concept of what is a process vs. what is a thread.
amluto 9y ago
> Those are only saved/restored when switching between processes not between threads. No, those registers are per-thread. The only things that are per-process are the page tables and, in special cases, CR4 and LDTR. If you want to see the code on Linux, look at switch_mm_irqs_off(). > Context switching when dealing with threads is typically done in software, not in hardware Hardware context switches (the x86 "task" mechanism) have been obsolete for a long time and are unavailable in long mode. > precisely so that registers that are not used (like the segment registers) don't get needlessly saved & restored. And that's the problem: the OS doesn't know that the registers are unused until it saves them. > Saving/restoring registers isn't even the expensive part of a context switch anyway. Switching address spaces, cache flushes/misses, etc... are all more expensive than saving/restoring registers. Go compare WRMSR to MSR_FS_BASE to the cost of a CR3 (page table) write. You might be surprised. And that CR3 write is about to get considerably faster, maybe in Linux 4.13, when my PCID patch set lands. (Yes, Linux will eventually use WRFSBASE instead, but that's a minefield and will take a while.)
- mee_too 9y ago
  This person switches threads :) But in practice, I guess this legacy architecture adds a nanosecond or two to a thread switch. Is that a big deal? How many switches does a desktop PC do in a second? How about an AWS/Azure/GCP server? I've never experienced lag in a game or app or web server due to slow thread switch. Server side async is on the rise anyway, minimizing number of threads and switches.
  - amluto 9y ago
    > But in practice, I guess this legacy architecture adds a nanosecond or two to a thread switch. Is that a big deal? I would guess the total wasted time is more like 500 cycles. This won't make your game lag, but it does mean that extremely low overhead synchronous IPC can't happen on x86.
    - mee_too 9y ago
      What types of programs are impacted by the lack of low overhead synchronous IPC?

bhouston 9y ago

> Those are only saved/restored when switching between processes not between threads. Context switching when dealing with threads is typically done in software, not in hardware, precisely so that registers that are not used (like the segment registers) don't get needlessly saved & restored. You are incorrect. Context switching is done for threads in HW. I think you are thinking of cooperative multi-threading (like pre-Windows 95, or nginx or node.js or V8) instead of true context-switching threading.

dom0 9y ago
> Context switching is done for threads in HW. Uhm, x86-64 can't switch between tasks/contexts in hardware.
kllrnohj 9y ago
All you need for preemptive multithreading is IRQ#0 to generate an interrupt. That's the entirety of it. Preemptive multiprocessing then needs paging and such to make isolated memory a thing as well, but still doesn't need HW context switching.

xorblurb 9y ago

Most registers including x86 segment registers need to be saved during context switches, regardless of its between threads or processes. E.g segment registers used for TLS. There are maybe optimisation for flat segments. > Context switching when dealing with threads is typically done in software, not in hardware I'm not sure any OS exists that does register saving in HW for switches between processes and in SW for switches between threads. Its especially doubtful for Linux, given it does not really have a very strong concept of what is a process vs. what is a thread.

amluto 9y ago

> Those are only saved/restored when switching between processes not between threads. No, those registers are per-thread. The only things that are per-process are the page tables and, in special cases, CR4 and LDTR. If you want to see the code on Linux, look at switch_mm_irqs_off(). > Context switching when dealing with threads is typically done in software, not in hardware Hardware context switches (the x86 "task" mechanism) have been obsolete for a long time and are unavailable in long mode. > precisely so that registers that are not used (like the segment registers) don't get needlessly saved & restored. And that's the problem: the OS doesn't know that the registers are unused until it saves them. > Saving/restoring registers isn't even the expensive part of a context switch anyway. Switching address spaces, cache flushes/misses, etc... are all more expensive than saving/restoring registers. Go compare WRMSR to MSR_FS_BASE to the cost of a CR3 (page table) write. You might be surprised. And that CR3 write is about to get considerably faster, maybe in Linux 4.13, when my PCID patch set lands. (Yes, Linux will eventually use WRFSBASE instead, but that's a minefield and will take a while.)

mee_too 9y ago
This person switches threads :) But in practice, I guess this legacy architecture adds a nanosecond or two to a thread switch. Is that a big deal? How many switches does a desktop PC do in a second? How about an AWS/Azure/GCP server? I've never experienced lag in a game or app or web server due to slow thread switch. Server side async is on the rise anyway, minimizing number of threads and switches.
- amluto 9y ago
  > But in practice, I guess this legacy architecture adds a nanosecond or two to a thread switch. Is that a big deal? I would guess the total wasted time is more like 500 cycles. This won't make your game lag, but it does mean that extremely low overhead synchronous IPC can't happen on x86.
  - mee_too 9y ago
    What types of programs are impacted by the lack of low overhead synchronous IPC?