[ros-kernel] I can boot ReactOS with 8 Mb!!

[Waldo Alvarez Cañizares]

Hi ppl:
 
Yes, it is real. After that a lot of swapping happens (i can boot ros 0.2 entIrely because ntdll is importing ole32.dll and i can't compIle those dll's yet, because I don't have the headers required I think, I'm using the winapi32-2.4, seems that you guys are using a modified version, and I can compile winebuild because of the getopt and such functions for parsing arguments, I changed bin2res to make it compile in windows, however it occurred with a very recent snapshot I can boot entirely) however ros 0.2 start to load user mode applications and most of the times it boots.
 
Watch the screenshot 0.2 final release booting with only 8 Mb. How was that posible? There is a bug in the nonpaged pool where when a block of memory is freed, the previous adjacent to is not coalesced, thus causing checkerboarding, fixing it is trivial but I have almost ready a patch that redesigns all things in there(I'm going to add that check to the macro VALIDATEPOOL to avoid it from happening again). I took away memory blocks headers out of the nonpaged pool and putted them in a stack that spans across a couple of pages avoiding address translations while searching over the tree across the block all over the memory. I removed those extra memset's, and changed the AVL tree by a Red-Black Tree. However, there are a couple of things. One I need to know the memory map of the reactos executive because I need a free available block to put the stack of headers (that is a structure that grows slowly but grows) right know I'm using 50 pages from the nonpaged pool right after the bitmap and before the first block, eventually it could be filled and cause weird things (I know I could allocate it from free block of the nonpaged pool or do it backwards but that can cause fragmentation and will make the code more complex). So can somebody please tell me how it is organized? I would appreciate that. Even better if it is documented somewhere in the docs.
 
I was thinking that it could be convenient to have more than one non paged pool. The normal one, and another without memory blocks for allocations you know that are never going to be freed. That could avoid checker boarding too and as a bonus it will require a little less memory. I'm thinking about having more but that's is an idea I have to mature yet. Also I could call the memory balancer from Mallocpage (I don't remember very well the name, the function that gives you back a physical page to later map it) and faced that the reactos cache manager uses the non paged pool (wich is locked at that moment, and that I can't unlock or I'll cause race conditions) I tested it unlocking the nonpaged pool so that the memory from the cache manager could be freed and I could boot reactos all the time (sure the chances to get a race condition are minimal but still possible) currently it boots sometimes. 
 
And finally I'm getting calls to allocate 8, 16, 23, 72 .. and such tiny quantities of memory. Hmm that's really bad actually a such a call can allocate up to one page which is a looot more than what you ask. I think that some of those requests could be putted on the stack (I knows the stack is small but that's an extreme) I have seen functions that for example have about 15 lines of code, allocate from the nonpaged pool a tiny structure and after that, free the memory. For example in the NTFS driver it happens and is not the only one. So I was thinking about putting a performance warning with a dbgprint for a while to call attention about those things (that is with a DbgPrint in ExAllocatePoolWithTag).
 
Well that was not the final, this one is. I have not seen conditional compilations about ExAllocatePoolWithTag That can take some time to do and it is going to be needed in the future with a clean release. I mean right now nobody is using ROS everyday to work or whatever, but in the future many will be and all that debugging stuff  will need to be removed, I mean it would be a shame having to use a checked build for every day's tasks. So guys start to think about that at least in a couple of moths.
 
Best Regards
Waldo Avarez
 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/ms-tnef
Size: 128624 bytes
Desc: not available
Url : http://reactos.com:8080/pipermail/ros-kernel/attachments/20040128/5c75ab50/attachment-0001.bin