It's UWAweek 47

help2002

This forum is provided to promote discussion amongst students enrolled in CITS2002 Systems Programming.
Please consider offering answers and suggestions to help other students! And if you fix a problem by following a suggestion here, it would be great if other interested students could see a short "Great, fixed it!"  followup message.
Displaying selected article
Showing 1 of 828 articles.
Currently 96 other people reading this forum.


 UWA week 40 (2nd semester, week 10) ↓
SVG not supported

Login to reply

👍?
helpful

"Kristiaan Maree" <24*1*7*3@s*u*e*t*u*a*e*u*a*> wrote:
> Hi, > if we load the page frames in sorted by page num the memory looks like this: > > process 1: 0,1,2,3 > process 2: 4,5,6,7 > process 3: 99,99,99,99 > process 4: 99,99,99,99 > > > RAM: 0,1,2,3,4,5,6,7 > DISK: 99,99,99,99,99,99,99 > > but if we get the instruction '3' there is no process 3 in main memory to swap to, > > instead are we supposed to put in 2 each to avoid this? > > e.g. > process 1: 0,1,99,99 > process 2: 2,3,99,99 > process 3: 4,5,99,99 > process 4: 6,7,99,99 > > RAM: 0,1,2,3,4,5,6,7 > DISK: 99,99,99,99,99,99,99,99 > > so now instruction 3 changes it to > > RAM: 0,1,2,99,4,5,6,7 > DISK: 99,99,99,99,99,99,3,99 > > or is there a better way?
I'm not sure what your question is about. Are you asking what happens if RAM is full and we are bringing in another process which isn't in RAM? In that case you would evict the page of *any process* with the lowest "last_accessed" time. Also, not sure what your RAM and DISK variable represent. Both RAM and DISK should only contain pointers to structures. You should only put 99 in the page table (to show that a page of a process isn't in RAM), it shouldn't appear in RAM or DISK. We do not modify virtual memory in any way. We assume all pages are always in virtual memory regardless if they are currently in RAM or not. We only ever change the contents RAM and the page table.

The University of Western Australia

Computer Science and Software Engineering

CRICOS Code: 00126G
Written by [email protected]
Powered by history
Feedback always welcome - it makes our software better!
Last modified  8:08AM Aug 25 2024
Privacy policy