4 ms·
I know the MMU doesn't make eviction decisions, but it does mark the "dirty" and "accessed" bits for pages. The GP was suggesting keeping track of the scheduli
by KMag 6y ago
I know the MMU doesn't make eviction decisions, but it does mark the "dirty" and "accessed" bits for pages.
The GP was suggesting keeping track of the scheduling priorities of tasks that were "accessing its[the page's] contents", not just keeping track of the highest priority task mapping a given page. This would require the MMU, as it's setting the dirty and accessed bits, to also keep track of the maximum priority that has set either the dirty or accessed bit.
Edit: from the GP's reply, it sounds like by "accessing" they really just meant mapping, not accessing is the sense of the accessed and dirty bits.
- johncolanduoni 6y agoThe dirty and accessed bits are per page table structure, so they are per-process. So you can at least take process priority into account, if not thread. In theory you could take thread priority into account by observing and resetting the dirty/accessed bits every context switch, but this would be unlikely to be worth it.
- toast0 6y ago> In theory you could take thread priority into account by observing and resetting the dirty/accessed bits every context switch, but this would be unlikely to be worth it. That would be most likely terrible (as you suggest). You might have better luck giving each thread a copy of the process page table, and keeping that in sync somehow (which also sounds terrible, but might be more workable)