Clarifying what different depths of rec are causing

[Tim Finley]

After discussion today, it seems like were are supposed to start swapping
out pages around a rec depth of 100 or so. That confused me, so I figured
I'd list what I thought was supposed to be happening at different rec
depths. (Note: I have not implemented any swapping in or out yet, just
dynamic stack growth).

First of all, every iteration of rec allocates an array of 512 ints on the
stack, so thats 512*4 bytes or 2KB.When my kernel starts up memory looks
like this.

8192KB memory detected, 1659 pages in freelist, 1048576 bytes in kernel
heap

After rec has been loaded (in shell) and created its pages for args,
code/data, stack etc I have 1627 pages free.

rec 1 -> For me no stack growth is necessary since the first stack page
has more than 2KB still available.

rec 2 -> First stack regrowth. (now 1626 pages free)

rec 4 -> Second stack regrowth (now 1625 pages free)

.. always get stack growths every two recursive depths

For me everything is the same until the stack overflows the page table
(the one arg-block page and 1023 stack pages is all the page table can
hold).

rec 2015 -> Here is the point where I have to create a new page table.
After this stack regrowth I have 603 pages free, which means I've
allocated 1024 pages (1627-603). (Still though the math doesn't quite add
up since rec 2015 should be only causing (2015-1)/2 or 1007 stack
growths.. hmm maybe I'm eating up extra pages somewhere).

rec 3204 -> Here is the point where I run out of free pages and hit the
TODO for finding a free page file.

Anyways, I think that I have a few bugs here and there still (since the
math isn't adding up perfectly), but I thought that this was the expected
behavior and that's why I'm confused why we are supposed to start paging
around rec 100. Anyone see if I'm totally off base with this?

[Iulian Neamtiu]

Your description is correct. Two things though:
- Since the argument to Recurse() decreases, you're gonna see the trace
numbers decrease like this:
Recurse 3300
Recurse 3299
....
Recurse 1


- You're not losing pages, those 1024-1007 = 17 'unexplainable'
are probably due to the fact that a stack frame is slighlty more than 2KB
because you need to push the arguments, the return address, etc.

Iulian

Post by Tim Finley
After discussion today, it seems like were are supposed to start swapping
out pages around a rec depth of 100 or so. That confused me, so I figured
I'd list what I thought was supposed to be happening at different rec
depths. (Note: I have not implemented any swapping in or out yet, just
dynamic stack growth).
First of all, every iteration of rec allocates an array of 512 ints on the
stack, so thats 512*4 bytes or 2KB.When my kernel starts up memory looks
like this.
8192KB memory detected, 1659 pages in freelist, 1048576 bytes in kernel
heap
After rec has been loaded (in shell) and created its pages for args,
code/data, stack etc I have 1627 pages free.
rec 1 -> For me no stack growth is necessary since the first stack page
has more than 2KB still available.
rec 2 -> First stack regrowth. (now 1626 pages free)
rec 4 -> Second stack regrowth (now 1625 pages free)
.. always get stack growths every two recursive depths
For me everything is the same until the stack overflows the page table
(the one arg-block page and 1023 stack pages is all the page table can
hold).
rec 2015 -> Here is the point where I have to create a new page table.
After this stack regrowth I have 603 pages free, which means I've
allocated 1024 pages (1627-603). (Still though the math doesn't quite add
up since rec 2015 should be only causing (2015-1)/2 or 1007 stack
growths.. hmm maybe I'm eating up extra pages somewhere).
rec 3204 -> Here is the point where I run out of free pages and hit the
TODO for finding a free page file.
Anyways, I think that I have a few bugs here and there still (since the
math isn't adding up perfectly), but I thought that this was the expected
behavior and that's why I'm confused why we are supposed to start paging
around rec 100. Anyone see if I'm totally off base with this?

[Tim Finley]

Oh thanks, I see that I was confused since I was looking from the opposite
perspective. Thanks for clearing that up.

Tim