3 ms·

No, I didn't :) All I did in my original comment was simply to point out to ajross that system calls don't always cause context switches. It's a common misconce

by dhess 18y ago

No, I didn't :) All I did in my original comment was simply to point out to ajross that system calls don't always cause context switches. It's a common misconception, not unique to ajross, of course, that a protection domain crossing requires a context switch, so I was making what I hoped was a helpful observation. I didn't say anything at all about disk reads in that original comment, nor about the merits of mmap vs. seek+read! I'm glad we agree on my second comment, in any case. :)

ajross 18y ago
I think we're quibbling about terminology. I'm not sure of the difference between a "protection domain crossing" (not a common term, AFAIK) and a "context switch" (pervasive jargon). You seem to be indicating that the latter always involves a separate process, which of course is more expensive (on most architectures) due to cache issues. I'm using the term to mean a switch between two execution domains.
- dhess 18y ago
  Sorry, you're right, "protection domain crossing" probably isn't common jargon. It's a holdover from my time as a processor architect on IA-64. It means privilege escalation. Anyway, in any common parlance of the term "context switch" I've ever seen, the amount of state switched to take a system call is much less (edit: oops, originally said 'greater' ;) than the amount of state switched in a context switch. At the very least, a context switch should mean the save and restore of user-level register state, which isn't necessary for a system call. You certainly wouldn't want to do that just to make a system call on a typical RISC architecture with 30-something registers! After all, from the perspective of the caller, it's just a special procedure call. The compiler and system call entry point can even use the same argument-passing convention. I wrote at least part of (maybe most, can't remember anymore :) the "recommended" context switch handler for IA-64. It was significantly more expensive than the system call handler. IA-64 dedicated quite a bit of hardware to making system calls cheap. If I recall correctly, besides a few privileged registers, the only thing we changed was the location of the register stack engine's backing store. That's just a single user-level register. (You don't want to spill registers with potentially privileged state into user space.) Anyway, this is way off-topic now and I don't think anybody's interested other than the three of us, so that's the last I'll say about it.
  - tptacek 18y ago
    Well, here's where this gets fun: most of the kernels we work with are structured like event loops, and disk I/O is asynchronous. When you issue a read vnop in a Unix kernel, your process will probably yield back to the scheduler loop, incurring the out switch and the in switch. This mmap vs. read argument is as old as the hills. I picked a side a long time ago; keep it simple.

by dhess 18y ago

ajross 18y ago

I think we're quibbling about terminology. I'm not sure of the difference between a "protection domain crossing" (not a common term, AFAIK) and a "context switch" (pervasive jargon). You seem to be indicating that the latter always involves a separate process, which of course is more expensive (on most architectures) due to cache issues. I'm using the term to mean a switch between two execution domains.

dhess 18y ago
Sorry, you're right, "protection domain crossing" probably isn't common jargon. It's a holdover from my time as a processor architect on IA-64. It means privilege escalation. Anyway, in any common parlance of the term "context switch" I've ever seen, the amount of state switched to take a system call is much less (edit: oops, originally said 'greater' ;) than the amount of state switched in a context switch. At the very least, a context switch should mean the save and restore of user-level register state, which isn't necessary for a system call. You certainly wouldn't want to do that just to make a system call on a typical RISC architecture with 30-something registers! After all, from the perspective of the caller, it's just a special procedure call. The compiler and system call entry point can even use the same argument-passing convention. I wrote at least part of (maybe most, can't remember anymore :) the "recommended" context switch handler for IA-64. It was significantly more expensive than the system call handler. IA-64 dedicated quite a bit of hardware to making system calls cheap. If I recall correctly, besides a few privileged registers, the only thing we changed was the location of the register stack engine's backing store. That's just a single user-level register. (You don't want to spill registers with potentially privileged state into user space.) Anyway, this is way off-topic now and I don't think anybody's interested other than the three of us, so that's the last I'll say about it.
- tptacek 18y ago
  Well, here's where this gets fun: most of the kernels we work with are structured like event loops, and disk I/O is asynchronous. When you issue a read vnop in a Unix kernel, your process will probably yield back to the scheduler loop, incurring the out switch and the in switch. This mmap vs. read argument is as old as the hills. I picked a side a long time ago; keep it simple.