| View previous topic :: View next topic |
| Author |
Message |
Robbert Dam
Guest
|
 Posted: Tue Oct 21, 2008 1:48 pm Post subject: Debugging page faults |
 |
|
Hi all,
I'm developing a large, time-critical, Linux program. I noticed that
my application causes quite a number of (minor) page faults during
operation. I don't know where they come from - it probably accesses
shared memory, but I'm not aware of any code in my app. that does
this.
My question: is there a way to debug these page faults? Is there a way
to generate a backtrace when the page fault occurs? Or can I capture
such page faults in my application?
Thanks,
Robbert |
|
| |
|
 Back to top |
Gil Hamilton
Guest
|
| Posted: Tue Oct 21, 2008 2:24 pm Post subject: Re: Debugging page faults |
|
|
Robbert Dam <robbertdam@gmail.com> wrote in news:16efe941-10a8-43f0-
9c1d-fc3c7eb54b71@t41g2000hsc.googlegroups.com:
| Quote: | I'm developing a large, time-critical, Linux program. I noticed that
my application causes quite a number of (minor) page faults during
operation. I don't know where they come from - it probably accesses
shared memory, but I'm not aware of any code in my app. that does
this.
My question: is there a way to debug these page faults? Is there a way
to generate a backtrace when the page fault occurs? Or can I capture
such page faults in my application?
|
It's normal and unremarkable for your application to generate page
faults. In linux (and most other modern OSes), the operating system
doesn't load all of your code and data into memory immediately when your
program starts, it simply sets up internal data structures so that the
code and data can be found if/when they're later needed. So the pages
corresponding to your program code and data are "faulted in" --
essentially one at a time -- as you access them.
Once they've been allocated and/or read into memory, they are likely to
remain there as long as they're being used regularly (also assuming you
have an adequate amount of physical memory).
Likewise, if you allocate some large buffers, for example, you'll find
that in actuality the operating system merely did some bookkeeping at
the time you did the allocation. The memory won't actually be made
available to your process until your program attempts to access it.
This will cause a page fault; physical memory is then made available to
your process, "swapping" some other page to the paging device if
necessary (hopefully a page that hasn't been used recently by your
pjrogram or any another).
I would not worry about the page faults at all unless you see
significant numbers of them occurring in time-critical sections of code
long after the program was started.
In any case, I'm not aware of any way your application can trap these
faults directly -- they are handled by the OS transparently.
GH |
|
| |
|
| Back to top |
Robbert Dam
Guest
|
| Posted: Tue Oct 21, 2008 2:34 pm Post subject: Re: Debugging page faults |
|
|
On 21 okt, 16:08, Rainer Weikusat <rweiku...@mssgmbh.com> wrote:
| Quote: | Robbert Dam <robbert...@gmail.com> writes:
I'm developing a large, time-critical, Linux program. I noticed that
my application causes quite a number of (minor) page faults during
operation. I don't know where they come from - it probably accesses
shared memory, but I'm not aware of any code in my app. that does
this.
A 'minor page fault' means the application attempted to access a
memory page which wasn't marked as 'present' in the associated set of
page tables but in memory nevertheless (a 'major fault' would be one
involving actual disk I/O). There is no reason to 'debug' these (the
'fault' just means a processor exception was generated for some
reason).
|
You're right, the term "debugging" was not correctly chosen. I want to
_optimize_ my application, because these page faults decrease my
applications performance (and I believe they should not be necessary). |
|
| |
|
| Back to top |
David Schwartz
Guest
|
| Posted: Tue Oct 21, 2008 5:31 pm Post subject: Re: Debugging page faults |
|
|
On Oct 21, 6:48 am, Robbert Dam <robbert...@gmail.com> wrote:
| Quote: | I'm developing a large, time-critical, Linux program. I noticed that
my application causes quite a number of (minor) page faults during
operation. I don't know where they come from - it probably accesses
shared memory, but I'm not aware of any code in my app. that does
this.
My question: is there a way to debug these page faults? Is there a way
to generate a backtrace when the page fault occurs? Or can I capture
such page faults in my application?
|
You are almost certainly incorrect in your implicit assumption that
these minor page faults have anything to do with your application's
performance. Minor page faults are a normal part of your operating
system's page cache aging and replacement logic.
DS |
|
| |
|
| Back to top |
Rainer Weikusat
Guest
|
| Posted: Tue Oct 21, 2008 7:08 pm Post subject: Re: Debugging page faults |
|
|
Robbert Dam <robbertdam@gmail.com> writes:
| Quote: | I'm developing a large, time-critical, Linux program. I noticed that
my application causes quite a number of (minor) page faults during
operation. I don't know where they come from - it probably accesses
shared memory, but I'm not aware of any code in my app. that does
this.
|
A 'minor page fault' means the application attempted to access a
memory page which wasn't marked as 'present' in the associated set of
page tables but in memory nevertheless (a 'major fault' would be one
involving actual disk I/O). There is no reason to 'debug' these (the
'fault' just means a processor exception was generated for some
reason). |
|
| |
|
| Back to top |
Josef Moellers
Guest
|
| Posted: Tue Oct 21, 2008 7:29 pm Post subject: Re: Debugging page faults |
|
|
Robbert Dam wrote:
| Quote: | Hi all,
I'm developing a large, time-critical, Linux program. I noticed that
my application causes quite a number of (minor) page faults during
operation. I don't know where they come from - it probably accesses
shared memory, but I'm not aware of any code in my app. that does
this.
|
It may very well be a "feature" of your hardware. E.g. not all hardware
has "used" bits to aid the OS in determining pages which have not been
used for some time. In this case, the page is marked as "Not Present"
and a ("soft") page fault is used to mark the page as "used". Also, some
hardware does not have a "dirty" bits to mark data pages that need to be
paged out before being reused. In this case, the clean pages are set to
"Write Protected" and a ("soft") page fault is then used to set a
software "Dirty" bit.
--
These are my personal views and not those of Fujitsu Siemens Computers!
Josef Möllers (Pinguinpfleger bei FSC)
If failure had no penalty success would not be a prize (T. Pratchett)
Company Details: http://www.fujitsu-siemens.com/imprint.html |
|
| |
|
| Back to top |
Robbert Dam
Guest
|
| Posted: Wed Oct 22, 2008 6:25 am Post subject: Re: Debugging page faults |
|
|
On 21 okt, 19:31, David Schwartz <dav...@webmaster.com> wrote:
| Quote: | On Oct 21, 6:48 am, Robbert Dam <robbert...@gmail.com> wrote:
I would not worry about the page faults at all unless you see
significant numbers of them occurring in time-critical sections of code
long after the program was started.
|
Well, this is actually the case. My program handles telephone calls,
and I see page faults occuring during almost every call setup,
regardless of how long the system was running. The program runs on
systems with plenty of memory (typically it only uses 20% of the
available memory).
| Quote: | You are almost certainly incorrect in your implicit assumption that
these minor page faults have anything to do with your application's
performance. Minor page faults are a normal part of your operating
system's page cache aging and replacement logic.
|
You may be right, maybe their effect on the performance is really
minor, I'm just looking for a way to find out what causes them during
normal operation and during time critical operations.
Thanks,
--Robbert |
|
| |
|
| Back to top |
David Schwartz
Guest
|
| Posted: Wed Oct 22, 2008 3:25 pm Post subject: Re: Debugging page faults |
|
|
On Oct 21, 11:25 pm, Robbert Dam <robbert...@gmail.com> wrote:
| Quote: | You may be right, maybe their effect on the performance is really
minor, I'm just looking for a way to find out what causes them during
normal operation and during time critical operations.
|
If you have a performance problem, why not troubleshoot it instead?
That's much more likely to yield useful results than investigating
your operating system's page cache aging, page modification detection,
COW, and page replacement logic. Odds are that works just fine.
DS |
|
| |
|
| Back to top |
|
