<ul>
<li><a href="#intro" name="TOCintro">Introduction</a></li>
+<ul>
+<li><a href="#arch" name="TOCarch">Supported architectures</a></li>
+</ul>
<li><a href="#section1" name="TOCsection1">Installing LTTng and LTTV from
sources</a></li>
<br>
<br>
-Supported architectures :
+<h3><a href="#TOCarch" name="arch">Supported architectures</a></h3>
<br>
LTTng :<br>
<br>
<li> ARM (with limited timestamping precision, e.g. 1HZ. Need
architecture-specific support for better precision)
<li> MIPS
+<li> sh (partial architecture-specific instrumentation)
+<li> sparc64 (partial architecture-specific instrumentation)
+<li> s390 (partial architecture-specific instrumentation)
+<li> Other architectures supported without architecture-specific instrumentation
+and with low-resolution timestamps.<br>
<br>
<br>
LTTV :<br>
and to help them solve hard to reproduce problems. They have had
success with such tracing approach to fix "rare disk delay" issues and
VM-related issues presented in this article :
-
- * "Linux Kernel Debugging on Google-sized clusters at Ottawa Linux
- Symposium 2007"
- http://ltt.polymtl.ca/papers/bligh-Reprint.pdf
-
+<ul>
+ <li> <a href="http://ltt.polymtl.ca/papers/bligh-Reprint.pdf">Linux Kernel
+Debugging on Google-sized clusters at Ottawa Linux
+ Symposium 2007</a>
+</ul>
<li> IBM Research have had problems with Commercial Scale-out applications,
which are being an increasing trend to split large server workloads.
They used LTTng successfully to solve a distributed filesystem-related