public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andreas Ferber <aferber@techfak.uni-bielefeld.de>
To: Karim Yaghmour <karim@opersys.com>
Cc: Ingo Molnar <mingo@elte.hu>,
	Linus Torvalds <torvalds@transmeta.com>,
	Roman Zippel <zippel@linux-m68k.org>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	LTT-Dev <ltt-dev@shafik.org>
Subject: Re: [PATCH] LTT for 2.5.38 1/9: Core infrastructure
Date: Mon, 23 Sep 2002 22:11:17 +0200	[thread overview]
Message-ID: <20020923221117.A29758@devcon.net> (raw)
In-Reply-To: <3D8F2F4C.BC5B82C@opersys.com>; from karim@opersys.com on Mon, Sep 23, 2002 at 11:12:12AM -0400

On Mon, Sep 23, 2002 at 11:12:12AM -0400, Karim Yaghmour wrote:
> 
> Sure, for performance measurements it's the admin, but per my earlier
> descriptions:
> - users who want to debug synchronization problems of their own tasks
> shouldn't see the kernel's behavior.
> - users who want to log custom events separate from the kernel events
> don't want to see the kernel's beavhior.

Fairly simple to achieve: provide some sort of userspace trace daemon
from which the users request the trace events they want to see
(communicating through standard IPC channels). The daemon provides a
unified event mask to the kernel (to prevent unnecessary overhead in
the kernel proper) and dispatches the events read from the kernel.
AFAICS LTT doesn't try to achieve realtime event monitoring, so
somewhat delaying the event propagation to the final receiver should
not be a problem (at least as long as it generally stays within a
reasonable timewindow, which should be no problem as long as the
system is not heavily overloaded, in which case in-kernel dispatching
would be nothing better).

Apart from taking complexity out of the kernel it also reduces the
tracing impact in case of event bursts because (provided the
ringbuffer is large enough) the (potentially timeconsuming in case of
many active tracers) dispatching of events is decoupled (in time) from
the event recording.

You will have to record uid/gid/pid/whatever criteria you might think
of with the event, somewhat enlarging (by a few bytes) a single event
record (don't know how much of this data you are currently gathering),
but that is a minor tradeoff IMHO.

Andreas
-- 
       Andreas Ferber - dev/consulting GmbH - Bielefeld, FRG
     ---------------------------------------------------------
         +49 521 1365800 - af@devcon.net - www.devcon.net

  reply	other threads:[~2002-09-23 20:06 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-09-22  5:43 [PATCH] LTT for 2.5.38 1/9: Core infrastructure Karim Yaghmour
2002-09-22 10:42 ` Ingo Molnar
2002-09-22 10:50   ` Ingo Molnar
2002-09-22 17:26   ` Roman Zippel
2002-09-22 18:35     ` Linus Torvalds
2002-09-22 19:18       ` Karim Yaghmour
2002-09-22 19:40         ` Ingo Molnar
2002-09-22 22:09           ` Karim Yaghmour
2002-09-22 22:24             ` Ingo Molnar
2002-09-22 22:41               ` Karim Yaghmour
2002-09-22 22:59                 ` Ingo Molnar
2002-09-22 22:50             ` Ingo Molnar
2002-09-22 23:32               ` Karim Yaghmour
2002-09-23  7:41                 ` Ingo Molnar
2002-09-23 15:12                   ` Karim Yaghmour
2002-09-23 20:11                     ` Andreas Ferber [this message]
2002-09-23 23:31                       ` Karim Yaghmour
2002-09-22 21:29       ` [ltt-dev] " bob
2002-09-22 19:06   ` Karim Yaghmour
2002-09-22 19:33     ` Karim Yaghmour
2002-09-22 21:20   ` [ltt-dev] " bob
2002-09-22 21:39     ` Ingo Molnar
2002-09-22 22:37       ` bob
2002-09-22 22:55         ` Ingo Molnar
2002-09-22 22:52           ` bob
2002-09-22 23:02             ` Ingo Molnar
2002-09-22 23:03               ` bob
2002-09-22 23:19                 ` Ingo Molnar
2002-09-22 23:50                   ` bob
2002-09-22 23:32             ` Ingo Molnar
2002-09-23  0:07               ` bob
2002-09-23  7:27                 ` Ingo Molnar
2002-09-23 13:59                   ` bob
2002-09-23  0:08               ` Karim Yaghmour
2002-09-22 22:58         ` Karim Yaghmour
     [not found] <Pine.LNX.4.44.0209221830400.8911-100000@serv.suse.lists.linux.kernel>
     [not found] ` <Pine.LNX.4.44.0209221130060.1455-100000@home.transmeta.com.suse.lists.linux.kernel>
2002-09-22 19:27   ` Andi Kleen
2002-09-24  1:07     ` john slee
2002-09-24 11:40       ` Andi Kleen

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=20020923221117.A29758@devcon.net \
    --to=aferber@techfak.uni-bielefeld.de \
    --cc=karim@opersys.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ltt-dev@shafik.org \
    --cc=mingo@elte.hu \
    --cc=torvalds@transmeta.com \
    --cc=zippel@linux-m68k.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