This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: reducing cost of user-space probes
- From: Josh Stone <jistone at redhat dot com>
- To: David Smith <dsmith at redhat dot com>, "O Mahony, Billy" <billy dot o dot mahony at intel dot com>
- Cc: "systemtap at sourceware dot org" <systemtap at sourceware dot org>
- Date: Mon, 24 Apr 2017 11:37:37 -0700
- Subject: Re: reducing cost of user-space probes
- Authentication-results: sourceware.org; auth=none
- Authentication-results: ext-mx05.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com
- Authentication-results: ext-mx05.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=jistone at redhat dot com
- Dkim-filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 8FAA813A5E
- Dmarc-filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 8FAA813A5E
- References: <03135AEA779D444E90975C2703F148DC2F8B6BED@IRSMSX107.ger.corp.intel.com> <CAKFOr-a3c-dTGBwb8tYi8O7vYXzeBoBxsChN_mty2vrJ_Bb_tg@mail.gmail.com>
On 04/24/2017 08:49 AM, David Smith wrote:
>> Does this mean that each time the probe is hit that a system call is made to this new .ko module? That would surely mean quite a lot of overhead. If this is correct, can this overhead be avoided for user space probes.
>
> The default "linux" runtime generates source for a kernel module,
> compiles and installs it behind the scenes. That's how the default
> runtime works. A system call is not made to the kernel module every
> time the probe is hit (even it it wanted to, kernel modules can't call
> system calls). Systemtap uses a kernel feature called 'uprobes' to
> handle user-space probe hits.
It's not a syscall, rather an int3 trap, but the overhead is roughly the
same. You pay the cost of a transition to and from ring0 *every* time,
even if you otherwise short-circuit the probe with 'next' or similar.
This is where "stap --runtime=dyninst" might shine, as the probe
executes entirely in-process.