mkanet
October 10th, 2010, 12:05 AM
First or all, I just want to make it clear that I understand mostly how page faults are generated. However, when I see a process utilize more than 200 times more page faults that all the programs I use, I know that there must be a component on girder that can be more efficiently coded.
Generally, when girder (or a part of girder needs access to a memory page thats not available in physical memory, it will then fault/make a hardware interrupt request to get it from external storage. This causes system performance degradation it increments continuously.
Ron, could you please take a close look at girder and see which component continuously asks for a piece of memory that's not there?... having to fault to external storage. I first thought it was the USBUIRT driver, but after i disabled it from the plugins of Girder 5, I still see the page faults increasing.
I am sure with some careful monitoring, you will be able to find the offending component and find a static way to ask for memory. This will also increase performance of girder as well.
Please let me know how I can help.
Thanks,
Michael
Generally, when girder (or a part of girder needs access to a memory page thats not available in physical memory, it will then fault/make a hardware interrupt request to get it from external storage. This causes system performance degradation it increments continuously.
Ron, could you please take a close look at girder and see which component continuously asks for a piece of memory that's not there?... having to fault to external storage. I first thought it was the USBUIRT driver, but after i disabled it from the plugins of Girder 5, I still see the page faults increasing.
I am sure with some careful monitoring, you will be able to find the offending component and find a static way to ask for memory. This will also increase performance of girder as well.
Please let me know how I can help.
Thanks,
Michael