Memory allocation in latest (Was Re: [coLinux-devel] Win32-Binary from 2004-08-16, Kernel 2.6.8.1)

[Dan A. <da...@co...>]

On Wed, Aug 18, 2004 at 06:43:12PM +0800, par...@gm... wrote:

> C:\PROGRA~1\coLinux>colinux-daemon.exe -c colinux.default.xml -d
> Cooperative Linux Daemon, 0.6.2
> Compiled on Tue Aug 17 23:34:25 2004
> 
> daemon: exit code 8000e804
> daemon: error - CO_RC_ERROR_OUT_OF_MEMORY, line 58, file id 0

It's worth mentioning that I've reimplemented the page allocation for
the Windows port. This reimplementation uses fewer MDLs and doesn't
use MmAllocateNonCachedMemory(). This allocation method is less 
agressive *because* it doesn't use MmAllocateNonCachedMemory(), and
that's why sometimes coLinux loads and sometimes it exits with 
CO_RC_ERROR_OUT_OF_MEMORY. Let me explain.

The coLinux driver requires the functionality of allocating physical
pages from the host kernel. The pages aren't needed to be mapped into
the virtual kernel address space. In Linux, this is done simply using
alloc_pages(). When the amount of free pages is short, the Linux 
kernel starts to free cache pages. If memory is *really* short (almost
all the pages are program data and no swap is free), only then the 
allocation will starts failing.

However, in Windows, it's a different story. Allocating pages is done
by calling MmAllocatePagesForMdl() which also allocates an MDL struct
per call. It's more efficient to call it once to allocate a group of
pages because it would be wasteful to have one MDL per allocated page.

Mind the awful interface, the MmAllocatePagesForMdl() function's 
success conditions are not entirely clear to me. Sometimes Windows 
decides to free its cache and return pages, but sometimes it doesn't.
The old implementation called MmAllocateNonCachedMemory() when 
MmAllocatePagesForMdl() failed. MmAllocatePagesForMdl()'s allocation
seems to be more aggresive and causes Windows to free pages for it,
but the side effect we get is that we waste the virtual address 
space of the kernel since MmAllocatePagesForMdl() also maps the memory
it allocates. Moreover, this type of aggresive allocation is not healthy 
to the host kernel - suppose a driver would innocently try to allocate
right after us?

Anyway, I can extend the implementation to call MmAllocateNonCachedMemory(),
but I prefer if someone could suggest a better idea.

-- 
Dan Aloni
da...@co...