Jump to content
  • Advertisement

Archived

This topic is now archived and is closed to further replies.

Krylloan

A fast way to query page status in *nix?

This topic is 5543 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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.

Share this post


Link to post
Share on other sites
Advertisement
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.

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!