context-switch

I am asked to describe the steps involved in a context switch (1) between two different processes and (2) between two different threads in the same process. During a context switch, the kernel will save the context of the old process in its PCB and then load the saved context of the new process scheduled to run. Context switching between two different threads in the same process can be scheduled by the operating system so that they appear to execute in parallel, and is thus usually faster than context switches between two different processes. Is this too general or what would you add to

Let's say we have a CPU with 20 cores and a process with 20 CPU-intensive independent of each other threads: One thread per CPU core. I'm trying to figure out whether context switching happens in this case. I believe it happens because there are system processes in the operating system that need CPU-time too. I understand that there are different CPU architectures and some answers may vary but can you please explain: How context switching happens e.g. on Linux or Windows and some known CPU architectures? And what happens under the hood on modern hardware? What if we have 10 cores and 20

I want to learn and fill gaps in my knowledge with the help of this question. So, a user is running a thread (kernel-level) and it now calls yield (a system call I presume). The scheduler must now save the context of the current thread in the TCB (which is stored in the kernel somewhere) and choose another thread to run and loads its context and jump to its CS:EIP . To narrow things down, I am working on Linux running on top of x86 architecture. Now, I want to get into the details: So, first we have a system call: 1) The wrapper function for yield will push the system call arguments onto the

Originally I believed the overhead to a context-switch was the TLB being flushed. However I just saw on wikipedia: http://en.wikipedia.org/wiki/Translation_lookaside_buffer In 2008, both Intel (Nehalem)[18] and AMD (SVM)[19] have introduced tags as part of the TLB entry and dedicated hardware that checks the tag during lookup. Even though these are not fully exploited, it is envisioned that in the future, these tags will identify the address space to which every TLB entry belongs. Thus a context switch will not result in the flushing of the TLB – but just changing the tag of the current

I'm writing a small program in C, and I want to measure it's performance. I want to see how much time do it run in the processor and how many cache hit+misses has it made. Information about context switches and memory usage would be nice to have too. The program takes less than a second to execute. I like the information of /proc/[pid]/stat, but I don't know how to see it after the program has died/been killed. Any ideas? EDIT: I think Valgrind adds a lot of overhead. That's why I wanted a simple tool, like /proc/[pid]/stat, that is always there. Use perf : perf stat ./yourapp See the kernel

Could any one tell me what is exactly done in both situations? What is the main cost each of them? Abhay Buch The main distinction between a thread switch and a process switch is that during a thread switch, the virtual memory space remains the same, while it does not during a process switch. Both types involve handing control over to the operating system kernel to perform the context switch. The process of switching in and out of the OS kernel along with the cost of switching out the registers is the largest fixed cost of performing a context switch. A more fuzzy cost is that a context switch