Return-Path: <linux-kernel-owner+willy=40w.ods.org@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id <S261486AbSIWXWM>; Mon, 23 Sep 2002 19:22:12 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id <S261488AbSIWXWM>; Mon, 23 Sep 2002 19:22:12 -0400
Received: from nameservices.net ([208.234.25.16]:29778 "EHLO opersys.com")
	by vger.kernel.org with ESMTP id <S261486AbSIWXWI>;
	Mon, 23 Sep 2002 19:22:08 -0400
Message-ID: <3D8FA45C.382C7E42@opersys.com>
Date: Mon, 23 Sep 2002 19:31:40 -0400
From: Karim Yaghmour <karim@opersys.com>
Reply-To: karim@opersys.com
X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.4.19 i686)
X-Accept-Language: en, French/Canada, French/France, fr-FR, fr-CA
MIME-Version: 1.0
To: Andreas Ferber <aferber@techfak.uni-bielefeld.de>
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
References: <Pine.LNX.4.44.0209230929010.2659-100000@localhost.localdomain> <3D8F2F4C.BC5B82C@opersys.com> <20020923221117.A29758@devcon.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org
Content-Length: 2092
Lines: 42


Andreas Ferber wrote:
> 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.

This, though, is the rather simple scenario. What would you do with
events generated by a user-space application and for which the daemon
has no idea of the format? What if there are five such applications
running in parallel each asking for its own separate buffer? What
about the telco guys at the RAS BoF (any many others for that matter)
that want to have a flight recorder (i.e. you always keep one buffer
going ALL the time and you only check it when something bad happens)?
There really needs to be a way to handle multiple input and output
streams. Fortunately, nontheless, our preliminary work on this issue
indicates that the overhead is minimal (i.e. add a "channel ID" to
each event; the tracer then uses the ID to put the event in the right
buffer; no filtering at this level).

> 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.

Minimizing event size is pretty high on the list of priorities. A few
bytes more per event makes a huge difference when you know that there
are above 10,000 events per second for a middle to low speed machine.

Karim

===================================================
                 Karim Yaghmour
               karim@opersys.com
      Embedded and Real-Time Linux Expert
===================================================
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/