public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "H. Peter Anvin" <hpa@zytor.com>
To: Vaibhav Nagarnaik <vnagarnaik@google.com>
Cc: Steven Rostedt <rostedt@goodmis.org>,
	Frederic Weisbecker <fweisbec@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, David Sharp <dhsharp@google.com>,
	Justin Teravest <teravest@google.com>,
	Laurent Chavey <chavey@google.com>,
	x86@kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 4/6] trace: trace syscall in its handler not from ptrace handler
Date: Mon, 26 Mar 2012 22:00:50 -0700	[thread overview]
Message-ID: <4F714982.6020208@zytor.com> (raw)
In-Reply-To: <1332787168-20457-5-git-send-email-vnagarnaik@google.com>

On 03/26/2012 11:39 AM, Vaibhav Nagarnaik wrote:
> The syscalls are a tricky bunch to trace, because of their multitude and
> dynamic nature of the list. In order to solve this, a macro handled the
> sycalls handler definition and it was expanded into setting up the
> metadata for the syscall event. A handler hooked into the ptrace syscall
> tracer to check whether an invoked syscall was supposed to be traced.
> 
> This added latency to all the invoked syscalls, since they had to be
> checked for tracing and also affected the latency of syscall that was
> actually getting traced. For e.g., using a simple program which invokes
> getuid() in a repeated loop and calculates the average time per syscall
> invocation found a latency of 570 - 117 = 453 ns added to every traced
> syscall.
> 
> This patch changes the syscall macro expansion, to create a function
> that adds the entry and exit tracepoints for the given syscall so that
> the latency can be avoided. This was suggested by Mathieu Desnoyers in
> https://lkml.org/lkml/2010/10/13/337
> 
> After this patch, the latency added is 370 - 117 = 253 ns per invocation
> of a traced syscall. This is on par with a simple tracepoint added to
> any kernel code path.
> 
> This patch also makes syscall tracing architecture independent as there
> is no need to have a hook into the architecture specific syscall tracer
> functions.
> 

I am officially confused here.  You have a single, common, dispatch
point for all system calls -- why don't you use it?  That is of course
the system call table.  If you want to trace a system call, override the
entry point in the syscall table to point to a hook function which can
provide entry and exit hooks.  It's not even code, it's data, so you
don't even have to play the code patching song and dance routine
(although you may have to map it read/write which is normally not the
case for security reasons.)

The best part is that the cost for an untraced system call is *zero*.

	-hpa


  reply	other threads:[~2012-03-27  5:01 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-26 18:39 [PATCH 0/6] Enhance and speed up syscall tracing Vaibhav Nagarnaik
2012-03-26 18:39 ` [PATCH 1/6] trace: syscalls.h - cleanup and simplify SYSCALL_METADATA() Vaibhav Nagarnaik
2012-03-26 18:39 ` [PATCH 2/6] trace: add support for 32 bit compat syscalls on x86_64 Vaibhav Nagarnaik
2012-03-27  4:49   ` H. Peter Anvin
2012-03-28 21:10     ` Vaibhav Nagarnaik
2012-03-28 21:11       ` Vaibhav Nagarnaik
2012-03-28 23:00         ` Vaibhav Nagarnaik
2012-03-26 18:39 ` [PATCH 3/6] trace: Refactor ftrace syscall macros to make them more readable Vaibhav Nagarnaik
2012-03-26 18:39 ` [PATCH 4/6] trace: trace syscall in its handler not from ptrace handler Vaibhav Nagarnaik
2012-03-27  5:00   ` H. Peter Anvin [this message]
2012-03-28 18:23     ` Vaibhav Nagarnaik
2012-03-29  2:43       ` H. Peter Anvin
2012-03-29  2:59         ` Steven Rostedt
2012-03-29  3:15           ` H. Peter Anvin
2012-03-29  3:02         ` Vaibhav Nagarnaik
2012-03-29  3:16           ` H. Peter Anvin
2012-03-29  6:20           ` Ingo Molnar
2012-03-29 19:02             ` Vaibhav Nagarnaik
2012-03-29 19:12               ` H. Peter Anvin
2012-03-29 19:43                 ` Vaibhav Nagarnaik
2012-03-29 20:06                   ` H. Peter Anvin
2012-03-29 22:40                     ` David Sharp
2012-03-29 22:44                       ` H. Peter Anvin
2012-03-30 12:06                       ` Frederic Weisbecker
2012-03-30 11:57                     ` Frederic Weisbecker
2012-03-29 22:44                 ` David Sharp
2012-03-29 22:48                   ` H. Peter Anvin
2012-03-26 18:39 ` [PATCH 5/6] trace: raw_syscalls: Mark compat syscalls in the MSB of the syscall number Vaibhav Nagarnaik
2012-03-26 18:39 ` [PATCH 6/6] trace: get rid of the enabled_*_syscalls bitmaps Vaibhav Nagarnaik

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4F714982.6020208@zytor.com \
    --to=hpa@zytor.com \
    --cc=chavey@google.com \
    --cc=dhsharp@google.com \
    --cc=fweisbec@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=rostedt@goodmis.org \
    --cc=teravest@google.com \
    --cc=tglx@linutronix.de \
    --cc=vnagarnaik@google.com \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox