public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andi Kleen <ak@suse.de>
To: Timothy Miller <miller@techsource.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: kernel 'simulator' and wave-form analysis tool?
Date: 05 Mar 2004 18:48:52 +0100	[thread overview]
Message-ID: <p7365dj422j.fsf@brahms.suse.de> (raw)
In-Reply-To: <4048B36E.8000605@techsource.com.suse.lists.linux.kernel>

Timothy Miller <miller@techsource.com> writes:

> Would it be a productive use of my time to work on this?

Not sure what you mean with waveform tool in this context, but
simulator logs can be indeed very useful to track down kernel bugs. I
used this excessively in the early days of the x86-64 port first with
the SimNow and later with the commercial Virtutech Simics
simulator. They both can generate a log file with all instructions and
all memory accesses. We wrote some post processing tools that added
the kernel symbols to that.  While processing these files (which can
quickly become several GB) was quite a stress test for less and the VM
it was often very useful. I can also only recommend XFS for such
uses, it seems to be by far the best file system for such workloads.

For example to find out who previously changed something in memory you
just need to search backwards for the same physical address.  The real
work usually was just to get a small enough "window" into the problem
to keep the log log files manageable. With logging the simulator runs
extremly slow and fills up disks quite quickly. I don't think it's
useful for complicated problems like races that take longer to trigger
(for longer running tests full logging is not practical), only for
something small and tricky that is relatively easy to repeat.

Writing a post processing tool that adds the symbols is not that complicated,
you can probably do it easily with any simulator log file. While it
would be possible to write a frontend to look for memory addresses
and automate other tasks just grep and less already work reasonably well.
With the amount of data involved you would probably want to do most
analysis as "batch" jobs.

-Andi

  parent reply	other threads:[~2004-03-05 17:48 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-03-05 17:05 kernel 'simulator' and wave-form analysis tool? Timothy Miller
     [not found] ` <4048B36E.8000605@techsource.com.suse.lists.linux.kernel>
2004-03-05 17:48   ` Andi Kleen [this message]
2004-03-05 18:04 ` Richard B. Johnson
2004-03-05 18:52   ` Timothy Miller
2004-03-06 11:13     ` John Bradford
2004-03-07  2:59       ` Mike Fedyk
2004-03-07 18:55         ` Jeff Dike
2004-03-08 16:33         ` Timothy Miller
2004-03-12 21:38           ` Herbert Poetzl

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=p7365dj422j.fsf@brahms.suse.de \
    --to=ak@suse.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=miller@techsource.com \
    /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