All of lore.kernel.org
 help / color / mirror / Atom feed
* pagefaults ...
@ 2013-06-14  5:18 Lars Segerlund
  2013-06-14  7:45 ` pagefaults Stanislav Meduna
  0 siblings, 1 reply; 3+ messages in thread
From: Lars Segerlund @ 2013-06-14  5:18 UTC (permalink / raw)
  To: linux-rt-users

 Hi,

 I have an application which should be realtime but apparently
generates page faults from a realtime context, I am trying to find a
way to get a stacktrace when this occurs, does anybody have any ideas
?

 I verified with some other testcases that the system actually looks
fine. And I would prefer to know where to look before I dive into the
code.

 I looked at ftrace and perf but haven't figured out how to get a
trace from the app, but I figured this must have occured before so I
better ask first.

 Any hints would be most appreciated !

 / regards, Lars Segerlund.

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: pagefaults ...
  2013-06-14  5:18 pagefaults Lars Segerlund
@ 2013-06-14  7:45 ` Stanislav Meduna
  2013-06-14 13:03   ` pagefaults Josh Cartwright
  0 siblings, 1 reply; 3+ messages in thread
From: Stanislav Meduna @ 2013-06-14  7:45 UTC (permalink / raw)
  To: Lars Segerlund; +Cc: linux-rt-users

On 14.06.2013 07:18, Lars Segerlund wrote:

>  I have an application which should be realtime but apparently
> generates page faults from a realtime context, I am trying to find a
> way to get a stacktrace when this occurs, does anybody have any ideas
> ?

Couuld you say more about your environment? Processor, kernel version,
what does you application do, how and when it is reproducible,
are these major or minor faults, ...?

If the system looks fine it is probably not the problem
I am hunting ( https://patchwork.kernel.org/patch/2581631/ )
but please look there whether you find some similarities.
I am still not able to reproduce that...

> I looked at ftrace and perf but haven't figured out how to get a
> trace from the app, but I figured this must have occured before so I
> better ask first.

For the start you can implant trace_printk into handle_pte_fault
to record the faulting address and then look in the /proc/<pid>/maps
where that address is.

For deciding when to stop the trace you can poll /proc/<pid>/task/<tid>/stat
and evaluate number of page faults. If you also enable tracing
the syscalls you can get an idea what the application was doing
right before it happened.

Basic questions:

- do you call mlockall(MCL_CURRENT | MCL_FUTURE) _before_ your
  threads are started?

- do the faulting threads allocate memory?

- do the faulting threads call kernel functions that might allocate memory?


Regards
-- 
                                      Stano


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: pagefaults ...
  2013-06-14  7:45 ` pagefaults Stanislav Meduna
@ 2013-06-14 13:03   ` Josh Cartwright
  0 siblings, 0 replies; 3+ messages in thread
From: Josh Cartwright @ 2013-06-14 13:03 UTC (permalink / raw)
  To: Lars Segerlund; +Cc: Stanislav Meduna, linux-rt-users

[-- Attachment #1: Type: text/plain, Size: 799 bytes --]

On Fri, Jun 14, 2013 at 09:45:17AM +0200, Stanislav Meduna wrote:
> On 14.06.2013 07:18, Lars Segerlund wrote:
>
> >  I have an application which should be realtime but apparently
> > generates page faults from a realtime context, I am trying to find a
> > way to get a stacktrace when this occurs, does anybody have any ideas
> > ?
>
[..]
>
> Basic questions:
>
> - do you call mlockall(MCL_CURRENT | MCL_FUTURE) _before_ your
>   threads are started?
>
> - do the faulting threads allocate memory?
>
> - do the faulting threads call kernel functions that might allocate memory?

Throwing in an additional question here that recently bit us:

  - does your application make use of fork(), popen(), daemon(), or any
    other call which under-the-hood invokes clone() with CLONE_VM not set?

  Josh

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2013-06-14 13:02 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-06-14  5:18 pagefaults Lars Segerlund
2013-06-14  7:45 ` pagefaults Stanislav Meduna
2013-06-14 13:03   ` pagefaults Josh Cartwright

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.