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

[art yerkes]

On Thu, 29 Jan 2004 19:46:08 +0100
"Hartmut Birr" <hartmut.birr at gmx.de> wrote:

> > -----Original Message-----
> > [mailto:ros-kernel-bounces at reactos.com] On
> > Sent: Thursday, January 29, 2004 12:22 AM
> > To: ReactOS Kernel List
> > Subject: I can boot ReactOS with 8 Mb!!
> > 
> > 
> > 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
> 
> If there is a bug in the non paged pool, I would like to fix this bug
> without other changes.
>  
> > 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.
> 
> Some time ago, I've implemented the AVL tree. I haven't written the real
> AVL code. It  was easier to found examples for an AVL tree as for an
> other balanced tree. If the Red-Black trees are faster or it is easier
> to understand the code, we should change to Red-Black trees.
> 
> > 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
> 
> You can look into MmInitVirtualMemory. There is the basic initialisation
> of reserved memory areas.
> 
> c0000000-zzzzzzzz ntoskrnl and boot drivers
> zzzzzzzz-yyyyyyyy ntoskrnl init section
> yyyyyyyy-xxxxxxxx ntoskrnl bss section
> xxxxxxxx-wwwwwwww boot parameter area
> wwwwwwww-vvvvvvvv non paged pool
> vvvvvvvv-uuuuuuuu kernel map
> uuuuuuuu-tttttttt paged pool
> d0000000-d00fffff low memory mapped into kernel space
> f0000000-f03f0000 page directories for a process
> ff000000-ff01ffff kpcr's for 32 processors
> ffdf0000-ffdf0fff shared user page mapped into kernel space
> 
> All other ranges are used by the cache manger or other function which
> does reserve memory.
>  
> > 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
> 
> You must always look the access to the nonpaged pool structures. If the
> access is not locked, a thread switching (or an other thread on a smp
> machine) can result in a second call to the pool functions.
> 
> > 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
> 
> The cache manger uses only the nonpaged pool for internal datas. The
> cache segments are allocate via the memory areas. 
> 
> > 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
> 
> For some datas is it possible to allocate them from the stack. But some,
> like rmap entries, must be always allocate from the pool.
> 

I wonder if anyone has thought of a 'small object' bitmap based allocator
for these small things.  It would probably save hordes of memory.  Some
things in the reactos kernel even allocate chains of 16 byte or less chunks.
my idea would be keep a list of pages, each of which would have a bitmap of
8-byte cells, and the cell data afterward.  That way, a low-overhead
allocator could be embedded in the current pool allocator.
-- 
"Should array indices start at 0 or 1? My compromise of 0.5 was rejected
 without, I thought, proper consideration."
   - S. Kelly-Bootle