Debugging page faults - Linux

This is a discussion on Debugging page faults - Linux ; 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 ...

+ Reply to Thread
Results 1 to 8 of 8

Thread: Debugging page faults

  1. 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

  2. Re: Debugging page faults

    Robbert Dam 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).




  3. Re: Debugging page faults

    Robbert Dam wrote in news:16efe941-10a8-43f0-
    9c1d-fc3c7eb54b71@t41g2000hsc.googlegroups.com:

    > 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

  4. Re: Debugging page faults

    Robbert Dam wrote:
    > 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

  5. Re: Debugging page faults

    On 21 okt, 16:08, Rainer Weikusat wrote:
    > Robbert Dam 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).

  6. Re: Debugging page faults

    On Oct 21, 6:48*am, Robbert Dam wrote:

    > 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

  7. Re: Debugging page faults

    On 21 okt, 19:31, David Schwartz wrote:
    > On Oct 21, 6:48*am, Robbert Dam 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).

    > 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



  8. Re: Debugging page faults

    On Oct 21, 11:25*pm, Robbert Dam wrote:

    > 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

+ Reply to Thread