Original thread: http://www.gamedev.net/community/forums/topic.asp?topic_id=174780 Does anyone know a fast way to test whether a page in linux is committed (eg, is in memory or disk, and won''t give an error when accessed), especially over a wide range of consecutive pages. Something akin to Windows''s VirtualQuery(). Thanks for all assistance.

er....

Why?

You should keep track of whats allocated yourself.

Yeah, I keep track of what I allocate.

But I don''t keep track of what other components allocate. I also don''t know what pages are taken up by the data, text and stack.

And since I''m not using heap allocation commands, just picking any old region in the virtual address space to use may mean I''m writing over a glTexture or dynamically linked library or something, which is not really a good idea.

er, the more you describe what you''re doing, the more it makes no sense.

why are you picking any old address to write to?

I''m not actually "picking any old address", it was just a figure of speech.

Ok, I''m allocating blocks of VMem in large powers of two, aligned to that same power of two.

Unfortunately, with todays 32 bit systems, there is the possibility of programs using up the majority of the available address space.

It would be a bad choice to pick an address just under the stack, or just above the primary heap, so I''m using a sort-of preferred-zone table that specifies what areas of memory to use first. (For windows, 1 GB to 1.5GB is the first zone).

But, even within 1 GB to 1.5 GB, sometimes some pages are used by other components. (I''m not sure what they are, but I did a page-scan using VirtualQuery on a program without doing any virtual mem management myself, and there were some used pages in this range).

Now when I need to allocate a block (Say a 4MB block) somewhere in VMem, to reserve it for my own allocator''s use, I need to first check that something else is not using it, like those random pages between 1GB and 1.5GB.

Standard heap management functions, like sbrk(), must have some way of knowing that they''re not growing over already used pages, but I''m not using standard heap management functions, because they only allocate consecutive pages.

As I understand, mmap() does not fail if you ask it to allocate pages already in use. And I cannot allow this to happen.

With the windows version, I map all possible blocks upon initialisation, then use that table to aid in block selection, to reduce the chance of VirtualAlloc(#, #, MEM_RESERVE, #) failing. If it fails, I mark the block as used by something else, so it''s not tested again.

If my table of the entire address space gets full (pretty unlikely), I re-test the memory, and if there''s no more available blocks, the allocater fails.

The linux version is actually going reasonably fast now, but it still has the possibility of misbehaving and overwriting pages used by other components. The chance is reduced by zoning, but is still possible.

The only current partial-solution I have is to try to access a every page within a block, and if every attempt is met with failure, use the block. However, this is not threadsafe, and does not detect pages that are committed but unable to be accessed. It is also very slow.

okay,

brk (sbrk is just a wrapper) and mmap are kernel calls. The kernel (of course) knows what your address space looks like, since it designed it for you.

If you take a look at /proc/#/maps you''ll see all the memory mappings that process has

There are better ways of reading that information, but I''ve never needed it and havn''t tried.