What's in the execution context? "Anything the processor needs to define the environment in which we're going to execute instructions" - program counter, register file, memory bank, stuff for syscalls.
eosofsky
The "memory bank" includes what a thread needs to know about its virtual memory mappings (the address space of the process). Also recall that the program counter is one of the registers.
apr
One question I have is, does the execution context also include the contents of the virtual memory of the process?
Another question: Two threads belonging to the same process will have the same mapping from virtual to physical addresses, but if they are being executed on two different cores (each having their own execution context), then how does making a new V -> P page mapping on one core get propagated to the other core immediately? Is this implemented in hardware or software?
albusshin
@apr In my own understanding: for your first question, the "execution context" is an abstract of the context of the current program's execution, and that includes the contents in the virtual memory of the process.
For your second question:
TL;DR: It's implemented in both software (OS) and hardware
For x86 processors and most OS implementations, the %cr3 register contains the address pointing to a page directory. The entries in page directory are addresses of the page tables: the V -> P mappings as mentioned in your question.
So if two cores are executing two different threads of the same program, the two %cr3 registers contain the same content, and thus making the two cores accessing the same page directory and page tables, so one core updating an V -> P mapping entry in one page table would have effect on the other core as well, since they are accessing the same memory chunk.
There is one more problem: TLB. If the TLB for one core cached one entry which is updated by another core, then there need to be interprocessor communication to invalidate the outdated entry in this core's TLB. TLB Shootdown is one of the solutions. The INVLPG instruction is specifically used for this purpose.
pajamajama
To summarize the parts of the processor as shown here + what each part does:
Fetch/Decode: the processor loads the instruction from memory and decodes it
ALU/Execute: the Arithmetic Logic Unit (ALU) performs arithmetic ops to execute the decoded instruction
Execution Context: the execution context contains info about the state of the processor that is needed in order to run a given instruction stream. Here, the processor updates the context of the executed instructions (e.g.: store the result of carrying out the instruction). As mentioned in the comments above, the execution context would include stuff like registers, program counter, stack pointer (PC + stack ptr are stored in registers in the execution context), etc
white
@apr
For your first question: does the execution context also include the contents of the virtual memory of the process?
In my understanding, it doesn't. Virtual memory provides every process a large, uniform and private address space. And it contains a lot of information like stack and heap status of its corresponding process. So it won't make any sense for execution context to include something that should be stored in disk and main memory. But I do believe execution context will include page tables to map virtual addresses to physical addresses.
What's in the execution context? "Anything the processor needs to define the environment in which we're going to execute instructions" - program counter, register file, memory bank, stuff for syscalls.
The "memory bank" includes what a thread needs to know about its virtual memory mappings (the address space of the process). Also recall that the program counter is one of the registers.
One question I have is, does the execution context also include the contents of the virtual memory of the process? Another question: Two threads belonging to the same process will have the same mapping from virtual to physical addresses, but if they are being executed on two different cores (each having their own execution context), then how does making a new V -> P page mapping on one core get propagated to the other core immediately? Is this implemented in hardware or software?
@apr In my own understanding: for your first question, the "execution context" is an abstract of the context of the current program's execution, and that includes the contents in the virtual memory of the process.
For your second question:
TL;DR: It's implemented in both software (OS) and hardware
For x86 processors and most OS implementations, the
%cr3register contains the address pointing to a page directory. The entries in page directory are addresses of the page tables: theV -> Pmappings as mentioned in your question.So if two cores are executing two different threads of the same program, the two
%cr3registers contain the same content, and thus making the two cores accessing the same page directory and page tables, so one core updating anV -> Pmapping entry in one page table would have effect on the other core as well, since they are accessing the same memory chunk.There is one more problem: TLB. If the TLB for one core cached one entry which is updated by another core, then there need to be interprocessor communication to invalidate the outdated entry in this core's TLB. TLB Shootdown is one of the solutions. The
INVLPGinstruction is specifically used for this purpose.To summarize the parts of the processor as shown here + what each part does:
Fetch/Decode: the processor loads the instruction from memory and decodes it
ALU/Execute: the Arithmetic Logic Unit (ALU) performs arithmetic ops to execute the decoded instruction
Execution Context: the execution context contains info about the state of the processor that is needed in order to run a given instruction stream. Here, the processor updates the context of the executed instructions (e.g.: store the result of carrying out the instruction). As mentioned in the comments above, the execution context would include stuff like registers, program counter, stack pointer (PC + stack ptr are stored in registers in the execution context), etc
@apr
For your first question: does the execution context also include the contents of the virtual memory of the process? In my understanding, it doesn't. Virtual memory provides every process a large, uniform and private address space. And it contains a lot of information like stack and heap status of its corresponding process. So it won't make any sense for execution context to include something that should be stored in disk and main memory. But I do believe execution context will include page tables to map virtual addresses to physical addresses.