linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: diekema@bucks.si.com (diekema_jon)
To: ford@vss.fsi.com (Brian Ford)
Cc: linuxppc-embedded@lists.linuxppc.org
Subject: Re: 2.5 or 2.4 kernel profiling
Date: Fri, 8 Dec 2000 12:41:15 -0500 (EST)	[thread overview]
Message-ID: <m144RWF-001SzYC@bucks> (raw)
In-Reply-To: <Pine.GSO.4.21.0012071210280.515-100000@eos> from "Brian Ford" at Dec 07, 2000 12:11:07 PM


> I am trying to do some kernel profiling on my EST8260 to determine the
> bottle neck in TCP and UDP thruput, but I can't seem to get any profile
> information.

What version of Linux are you using?  I have tried the LTT, Linux
Trace Toolbox under 2.4.0-test11.  LTT tracks a large number of
events, so it may give you a better handle as to what is happening
when.

http://www.opersys.com/LTT

+Kernel events tracing support
+CONFIG_TRACE
+  It is possible for the kernel to log important events to a tracing
+  driver. Doing so, enables the use of the generated traces in order
+  to reconstruct the dynamic behavior of the kernel, and hence the
+  whole system.
+
+  The tracing process contains 4 parts :
+      1) The logging of events by key parts of the kernel.
+      2) The trace driver that keeps the events in a data buffer.
+      3) A trace daemon that opens the trace driver and is notified
+         every time there is a certain quantity of data to read
+         from the trace driver (using SIG_IO).
+      4) A trace event data decoder that reads the accumulated data
+         and formats it in a human-readable format.
+
+  If you say Y or M here, the first part of the tracing process will
+  always take place. That is, critical parts of the kernel will call
+  upon the kernel tracing function. The data generated doesn't go
+  any further until a trace driver registers himself as such with the
+  kernel. Therefore, if you answer Y, then the driver will be part of
+  the kernel and the events will always proceed onto the driver and
+  if you say M, then the events will only proceed onto the driver when
+  it's module is loaded. Note that event's aren't logged in the driver
+  until the profiling daemon opens the device, configures it and
+  issues the "start" command through ioctl().
+
+  The impact of a fully functionnal system (kernel event logging +
+  driver event copying + active trace daemon) is of 2.5% for core events.
+  This means that for a task that took 100 seconds on a normal system, it
+  will take 102.5 seconds on a traced system. This is very low compared
+  to other profiling or tracing methods.
+
+  For more information on kernel tracing, the trace daemon or the event
+  decoder, please check the following address :
+       http://www.opersys.com/LTT

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

  reply	other threads:[~2000-12-08 17:41 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <Pine.GSO.4.21.0012071148420.515-100000@eos>
2000-12-07 18:11 ` 2.5 or 2.4 kernel profiling Brian Ford
2000-12-08 17:41   ` diekema_jon [this message]
2000-12-08 18:24     ` Brian Ford
2000-12-11  0:45   ` Graham Stoney
2000-12-11 15:27     ` Brian Ford
2000-12-12  2:36       ` Graham Stoney
2000-12-12  3:26         ` Dan Malek
2000-12-12  7:28           ` Graham Stoney
2000-12-12 16:32             ` Brian Ford
2000-12-12 16:58               ` Dan Malek
2000-12-12 17:17                 ` Brian Ford
2000-12-12 21:03                   ` Dan Malek
2000-12-13  1:15               ` Graham Stoney
2000-12-13 16:14                 ` Dan Malek
2000-12-13 17:23                   ` Arto Vuori
2000-12-13 17:33                     ` Dan Malek
2000-12-13 17:55                       ` Arto Vuori
2000-12-13 22:08                   ` Brian Ford
2000-12-13 22:45                     ` Jerry Van Baren
2000-12-13 22:53                     ` Dan Malek
2000-12-14 17:29                       ` FEC/FCC driver issues Brian Ford
2000-12-14  7:21                   ` 2.5 or 2.4 kernel profiling Graham Stoney
2000-12-14 16:58                     ` Dan Malek
2000-12-15  0:18                       ` Graham Stoney
2000-12-12 15:26         ` Brian Ford
2000-12-12 17:12           ` Jerry Van Baren

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=m144RWF-001SzYC@bucks \
    --to=diekema@bucks.si.com \
    --cc=ford@vss.fsi.com \
    --cc=linuxppc-embedded@lists.linuxppc.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;
as well as URLs for NNTP newsgroup(s).