Discussion:
paging out
(too old to reply)
c***@CSIC.UMD.EDU
2005-04-09 19:48:10 UTC
Permalink
i start to page out
at: Calling recurse
111 - 110 range.
which i believe is
perfectly fine as i
check how many free
pages are left and
there are none.
however, when i find
a page to page out
the first page i
find is the
"text/data" for the
user program. which
i also think is
right as it is the
first page that was
allocated via
Alloc_Pageable_Page.
that address turns
out to be
0x00036000. I page
it out and my
program runs down to
"recurse 109, 108"
then it needs to
page out again. so
it pages out the
next page. this
continues down to
"recurse 102" then
my program just
wants to write all
pages that exist to
the paging file
until i run out of
pages on the paging
file ( 220 pages i
think. from
[numSectors -
startSector] /
PAGE_SIZE ). i
believe i have taken
care of dealing with
the clock,
initPaging and
Find_Space_On_Paging_File
perfectly fine.
Write_to_Paging_File
is mildly correct.
however, i should be
able to get down to
" recurse 1" and
receive a "Read
Fault". at least
from my
understanding of
paging/Virtual
Memory.

Anyone have any
suggestions?
c***@CSIC.UMD.EDU
2005-04-10 00:26:36 UTC
Permalink
i'm rather lost at this point. i have printed out the address and the page
directory index. it seems to fault correctly up to 110 then needs to page out.
then i let it page out and keep faulting correctly up to 102. then it starts
faulting in the wrong address for some reason. it jumps from directory 1022 ( @
recurse 102 ) to directory 512. then just goes beserk. my stack growth works
perfectly fine. and i am able to pass the first time when the first page table is
filled with creating a new page table just fine ( @ recurse 1287 ). any
suggestions anyone?
Iulian Neamtiu
2005-04-10 02:52:11 UTC
Permalink
Faulting @ dir index 512 is OK I think, because that's in text/data
segment (slightly more than USER_VM_START). It's legit to swap out (and
in) one of those pages.

Iulian
Post by c***@CSIC.UMD.EDU
i'm rather lost at this point. i have printed out the address and the page
directory index. it seems to fault correctly up to 110 then needs to page out.
then i let it page out and keep faulting correctly up to 102. then it starts
recurse 102 ) to directory 512. then just goes beserk. my stack growth works
perfectly fine. and i am able to pass the first time when the first page table is
suggestions anyone?
Huyen Tue Dao
2005-04-10 17:25:51 UTC
Permalink
Post by c***@CSIC.UMD.EDU
i'm rather lost at this point. i have printed out the address and the page
directory index. it seems to fault correctly up to 110 then needs to page out.
then i let it page out and keep faulting correctly up to 102. then it starts
recurse 102 ) to directory 512. then just goes beserk. my stack growth works
perfectly fine. and i am able to pass the first time when the first page table is
suggestions anyone?
I think you may be having similar problems to what I was having. I got
to a point where I paged out the data/text segments in the first
directory entry, and then all of the sudden I'd get in this weird
infinite cycle of paging in and out the same three pages.

It seemed I was doing the LRU algorithm incorrectly. Initially, I had
gone through the page directory entries for the kernel memory, gotten
the struct Pages for each one to evaluate the clock and the flags;
however, before I was getting the accessed field from the page tables
for the physical pages, not the user pages that were using those
physical pages, the entry that's a field in the struct Page.

I think this is what I did and it seemed to fix my problem.

Hope it helps.
c***@CSIC.UMD.EDU
2005-04-10 18:06:00 UTC
Permalink
the way that i update the clock is that i have a function that goes through all
pages in the system. checks if the page is allocated and pageable. then checks the
accessed bit of the page. if it's 1 then update the clock to g_numTicks and set
the accessed bit to 0.

i call this function as the first line of Page_Fault_Handler.
from what i have seen, my algorithm is able to write 2 or 3 pages to the paging
file and handle those parts of the recurse fine. after those 3 or so pages it goes
and starts writing every page that is pageable and allocated to the paging file
until there are no more pages left in the paging file which should never happen
with rec.exe 3300

from my calculations, at the point that rec.exe 3300 starts to page out, it needs
approximately 50-60 pages. way less than the 220 pages of the system paging file.
Continue reading on narkive:
Loading...