• Advertisement

Archived

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

Pagefaults

This topic is 5100 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

I just ran a profiler on a small game engine i am working on an i noticed it gets around 500-700 pagefaults per second. This seems kinda high to me and i was wondering if anyone knows common things that cause this and how to prevent pagefaulting. Jon

Share this post


Link to post
Share on other sites
Advertisement
so basically its just windows reordering my stuff that causes this eh?

Share this post


Link to post
Share on other sites
Anyone tried using something like this? http://msdn.microsoft.com/library/default.asp?url=/library/en-us/memory/base/virtuallock.asp

sounds like it can lock your memory so you dont get pagefaulting....

Share this post


Link to post
Share on other sites
I noticed this too - you can get the windows task manager to show page faults. Winamps was flying up, and a lot of apps were going up pretty steadily.

Is a page fault just a miss of cached memory?

Share this post


Link to post
Share on other sites
High level of page faults are usually indicative of poor temporal and spatial locality of memory access. Reducing page faults can be done by reducing your process''s working set within a given time frame. There are a multitude of different ways to do that. Off the top of my head: use custom allocators to group temporally local objects in spatially local memory address, change data structures to favor fewer total allocations, taking advantage of multiple heaps if your compiler supports them, pre-processing batched data fetchs to so that they occur in a spatial local manner, and of course, the just-use-less-memory technique.

Share this post


Link to post
Share on other sites
quote:
Original post by jonr
Anyone tried using something like this? ...snip...
sounds like it can lock your memory so you dont get pagefaulting....


I find that in most cases VirtualLock() will actually hurt application performance. The OS tends to be a better judge of what needs to be paged out than the programmer.

Share this post


Link to post
Share on other sites
quote:
Original post by Evil Steve
Is a page fault just a miss of cached memory?


A page fault is when memory requested is not in the physical memory, so the virtual memory manager needs to fetch the requested information from the disk and place in physical memory.

When the memory requested is not the cache, it''s simply called a cache miss.

Share this post


Link to post
Share on other sites
I''m still sticking to what I said, use less memory.

find ways to do that, and the page faulting will disappear.

suggestions:
-optimize for size, not speed
-try to avoid referencing various large piles of data in tight loops, just try to stick to a minimal set.
-reduce quality of lossy things, like textures

Share this post


Link to post
Share on other sites
What sort of performance hit does a page fault incur? 50ms? It might be small, but if you get a page fault every time you go through your main loop, that''ll slow things down a hell of a lot...

Share this post


Link to post
Share on other sites
A page fault can''t possible take 50ms.. when working with virtual memory (usually by the OS), page faults occur all the time. IIRC from some online tutorial, the memory has to be swapped to disk, and when it needs to be accessed, it will generate a page fault to signal that it needs to be swapped to memory.

edit: Oh. SiCrane already said that.

Share this post


Link to post
Share on other sites
quote:
Original post by psykr
A page fault can''t possible take 50ms..



Yes. Consider the initial report - 500-700 page faults / second. That suggests something in the range of 1.5 - 2.0 ms. At 50 ms, 500 pfs would take 25 seconds.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
A page fault can be either hard or soft.

A soft pf means the requested page was in memory, but not mapped into the process'' working set (the page could either be in memory but mapped to another process'' address space, or on its way to be written to the pagefile).

A hard page fault means the page wasn''t in memory and has to be fetched from disk, in which case the thread will wait for i/o completion and another thread will be scheduled instead.

A hard pf will take at least 10-15ms due to disk i/o, normally probably 30-50ms. On a saturated system it could be much longer (seconds).

I wouldn''t necessarily worry only because I saw 500-700 pf/s, although it''s probably possible to lower that figure. Are you having performance problems also?

You already received the advise to minimize code size. In addition, try to minimize allocations from the heap.

instead of allocating on heap:

int* foo = new int[256];
func(foo);
delete[] foo;

try to keep memory on stack:

int foo[256];
func(foo);

You could play with the small block heap (see _set_sbh_threshold, don''t forget to check it''s return value) to minimize allocations from the OS.

If you have some data structure that you often allocate and free, try to re-use it instead.

Instead of:

void OnClientConnected()
{
m_clientdata = new ClientData();
}
void OnClientDisconnected()
{
delete m_clientdata;
}

you could have a pool of ClientData instances that you re-use.

void OnClientConnected()
{
m_clientdata = g_clientdataPool.Get();
}
void OnClientDisconnected()
{
m_clientdata.Reset();
g_clientdataPool.Put(m_clientdata);
}

If you have large data structures, make sure to keep minimal data size. For instance, don''t have an array of int:s if you only need an array of byte:s.

Share this post


Link to post
Share on other sites
thats all sound advice, its time for some good ol'' fashion code optimizing. Performance isnt bad yet but it can always be better

Share this post


Link to post
Share on other sites

  • Advertisement