Skip to main content
gamedev.net
🔒 Locked

Pagefaults

Started by jonr 13 replies 850+ views
Original Post
jonr
jonr
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
C-Junkie
C-Junkie
Simple, er maybe not so simple.

Use less memory.

heh.
jonr
jonr
so basically its just windows reordering my stuff that causes this eh?
jonr
jonr
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....
Evil Steve
Evil Steve
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?
SiCrane
SiCrane
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.
SiCrane
SiCrane
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.
SiCrane
SiCrane
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.
Shannon Barber
Shannon Barber
If anything uses memory mapped files (WinAmp might) every 4k of data read off disk will result in a page fault.
The trade-off between price and quality does not exist in Japan. Rather, the idea that high quality brings on cost reduction is widely accepted.-- Tajima & Matsubara
C-Junkie
C-Junkie
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
Evil Steve
Evil Steve
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...
psykr
psykr
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.
LessBread
LessBread
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.

"I thought what I'd do was, I'd pretend I was one of those deaf-mutes." - the Laughing Man
jonr
jonr
thats all sound advice, its time for some good ol'' fashion code optimizing. Performance isnt bad yet but it can always be better

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.

Sign in to reply to this topic.