Re: [RFC] Userspace tracing memory mappings

!MAILaRCHIVE_VOTE_RePLACE
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
To: Frank Ch. Eigler <fche@...>
Cc: Dave Hansen <haveblue@...>, <mbligh@...>, <linux-mm@...>, <linux-kernel@...>
Date: Wednesday, January 23, 2008 - 5:55 pm

* Frank Ch. Eigler (fche@redhat.com) wrote:

The kernel would provide :

- System-wide activation of markers located in userspace code
  example use : libc, NPTL tracing.
- Ability to extract buffers of a crashed process
- Ability to extract userspace tracing buffers upon kernel crash
- Activation of userspace tracing at the same time as the kernel tracing
  activation is done, without requiring messing up with signals.
- Potentially filtering on events coming from userspace, without messing
  up with signals.

Another point is early boot tracing : tracing processes such as init
requires to use syscalls rather than relying on debugfs/dev/proc file
operations. And we can't dump the information to the disk yet, so we
cannot expect the process itself to deal with file opening or socket
opening that soon. Therefore, we have to divide tracing in two distinct
actions : writing to the buffers and dumping the buffers (to disk or
though the network).

Another reason why we don't want to do everything is a single library is
that it would account the disk write time to the traced process. If we
do this from the kernel, we can know how many time it took because we
trace it. Another, better yet, reason for this is that if we want to
extract the data to disk or through the network, and want to get the
last trace bits of a segfaulted process, we have to share the buffers
with another process somehow. However, creating one extra process per
traced process is kind of awkward.

So the code itself would be a library in userspace. However, it would
interact both with the kernel for trace activation and with a daemon to
extract the information to disk or to the network. I start to think that
a userspace library would be sufficient for the userspace part of this
design (no need to modify vDSO).

And system V shared memory has a limit on the number of such memory
mapping one can have in the system that is way too low.

Does it explain the purpose of the kernel interaction better ?

Mathieu

-- 
Mathieu Desnoyers
Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68
--
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]

Messages in current thread:
[RFC] Userspace tracing memory mappings, Mathieu Desnoyers, (Wed Jan 23, 12:04 pm)
Re: [RFC] Userspace tracing memory mappings, Dave Hansen, (Wed Jan 23, 3:38 pm)
Re: [RFC] Userspace tracing memory mappings, Mathieu Desnoyers, (Wed Jan 23, 6:06 pm)
Re: [RFC] Userspace tracing memory mappings, Frank Ch. Eigler, (Wed Jan 23, 3:01 pm)
Re: [RFC] Userspace tracing memory mappings, Mathieu Desnoyers, (Wed Jan 23, 5:55 pm)