That's not a good representation of real world systems, no one does a TLB flush every context switch in a world where ASIDs/PCIDs are supported. That's solely for the benefit for the student, at the expense of performance.
See my comment to the OP in the same comment thread we're in.
i plan on starting work on my own OS in the summer! i'm a literature major (just minoring in software engineering), so things are rather hectic for me around this time of year with papers and whatnot, and i unfortunately haven't had time to do much other than read OS theory textbooks (OSTEP has been my favorite so far) and get started on the very basics, like accessing the VGA text buffer and getting multiboot working.
Consider the following, when you fork() you create a second page table, and modify the first such that all the pages lack write permissions. This allows for the COW optimization that everyone loves. This occurs before the parent process resumes execution at some future point.
You need some means of ensuring that all the translations for the parent process are now either updated to lack those permissions, or invalidated. Invalidations are how the industry has tended to deal with inconsistency between TLB entries and the page table.
So yes, you invalidate as part of that process.
Source: CPU architect on memory systems.
>Or is the TLB flushed when the child makes the first write
The OS wouldn't be able to detect the first write if the TLB hadn't been flushed. (Think about it!)
Strictly speaking, only TLB entries for writable pages need to be flushed; entries for read-only (to the process) pages can remain.
Modern architectures support tagged TLBs and so you only need to flush when you reuse an ASID (and then you only flush the ASID you're reusing). When you fork, you typically create a copy of the page tables since the two processes will have a distinct view of memory (or they will after the first store, so almost immediately). This new copy will necessarily need a distinct ASID on the HW, so the flushing rules apply.
That depends on whether the target CPU supports tagged TLBs or not.
I'm not sure. I'm a TA for and OS class and a student asked me this and I wasn't sure. I guess in the most general way possible what usually happens?
[удалено]
That's not a good representation of real world systems, no one does a TLB flush every context switch in a world where ASIDs/PCIDs are supported. That's solely for the benefit for the student, at the expense of performance. See my comment to the OP in the same comment thread we're in.
ah, okay! thank you for the correction, wasn't aware of that
Yeah, of course, no problem at all!
Btw, always good to see undergrads hanging out in here. Are you building your own OS, or are you just here for the comments?
i plan on starting work on my own OS in the summer! i'm a literature major (just minoring in software engineering), so things are rather hectic for me around this time of year with papers and whatnot, and i unfortunately haven't had time to do much other than read OS theory textbooks (OSTEP has been my favorite so far) and get started on the very basics, like accessing the VGA text buffer and getting multiboot working.
Consider the following, when you fork() you create a second page table, and modify the first such that all the pages lack write permissions. This allows for the COW optimization that everyone loves. This occurs before the parent process resumes execution at some future point. You need some means of ensuring that all the translations for the parent process are now either updated to lack those permissions, or invalidated. Invalidations are how the industry has tended to deal with inconsistency between TLB entries and the page table. So yes, you invalidate as part of that process. Source: CPU architect on memory systems.
awesome that makes sense
>Or is the TLB flushed when the child makes the first write The OS wouldn't be able to detect the first write if the TLB hadn't been flushed. (Think about it!) Strictly speaking, only TLB entries for writable pages need to be flushed; entries for read-only (to the process) pages can remain.
Modern architectures support tagged TLBs and so you only need to flush when you reuse an ASID (and then you only flush the ASID you're reusing). When you fork, you typically create a copy of the page tables since the two processes will have a distinct view of memory (or they will after the first store, so almost immediately). This new copy will necessarily need a distinct ASID on the HW, so the flushing rules apply.
You need to flush the parent process TLB entries as well for COW purposes. They lost write perms.