Subject:
|
Re: My problems with adding a Best Fit algorithm for memory management to kernel/mm.c
|
Newsgroups:
|
lugnet.robotics.rcx.legos
|
Date:
|
Sun, 7 Dec 2003 17:31:06 GMT
|
Viewed:
|
3884 times
|
| |
|
|
In lugnet.robotics.rcx.legos, Michael Martelli wrote:
> The results I am getting a very odd.
>
> If I load this version of the OS and then load my testing program (one which
> mallocs a few blocks, then frees some, and then mallocs a few more and then
> finally scans user memory and prints out the memory layout, i.e. the address,
> PID, size of each block) then it seems to allocate everything fine, except for
> one random block of memory which is size 7 in the after all the of OS tasks are
> allocated.
>
> But if I turn the RCX off then on either:
> (a) after downloading the program or
> (b)after just running the program
> and then run the program again, all of the OS tasks that were allocated now
> somehow must have their PID set to MM_FREE and then they are all joined together
> as 1 free block of memory beginning at mm_start. And then after that the user
> program is allocated (and is fine throughout the whole process, nothing happens
> to it, its PID is fine) the OS tasks get allocated again, and then from any time
> after that the memory layout remains the same (i.e. no other blocks get reset
> and joined to create a giant free block of memory).
>
> Does anyone have any idea what is going on? And why?
>
> The rest of my mm.c file is the same as the original and the same as my Best Fit
> version which worls perfectly.
So, if I understand you correctly, your concern is that the OS tasks move around
the first time you power off & on, but not anytime thereafter? Assuming this to
be the case, then:
1) When you first download BrickOS, there is a large chunk of memory at
[ADEA-EF2C). There are also a few smaller chunks in high memory, but for the
most part your worst fit algorithm will ignore these. From this large chunk
gets allocated the various OS tasks (and stacks, etc...) since the worst fit
algorithm picks the largest free chunk from which to allocate.
2) You download your test program and it gets allocated 6B words at B648.
3) You turn off the RCX and all the tasks are terminated and their memory freed
up. Every time you turn off the RCX, this memory will be freed. However, your
program will stay in memory. Since this is the case, it has fragmented the
initial large chunk of memory into two chunks: [ADEA,B648) and [B722,EF2C).
4) You turn on the RCX and BrickOS starts up the various OS tasks and these
allocate memory from the largest available memory chunk which is now at
[B722,EF2C).
5) Go to step 3.
So, downloading your test program has fragmented memory and causes any
subsequent allocations (using the worst fit algorithm) to use the largest free
memory block (which happens to be located after your program in memory).
There is one thing that bothers me which you did not mention. Here is the first
five lines of your second memory dump:
Addr PID Size
--------------------
ADCA 0000 042D
B648 AFDA 006B
B072 AD50 000A
B71A AD50 0040
B79E AD50 0004
See the address B072? It's not in sequential order. There are also two other
blocks at B74E and B766 in the same dump which are out of order. Are these
typos or perhaps transmission/reception errors from your test program?
Mark
|
|
Message has 1 Reply:
Message is in Reply To:
14 Messages in This Thread:
  
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
This Message and its Replies on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
