| Both sides previous revision Previous revision Next revision | Previous revision |
| kernelbugtriage [2008/01/25 15:48] – Thoughts on performance reports RobertWatson | kernelbugtriage [2022/07/13 01:23] (current) – Add Categories: NeedsContent, Stale. Remove Author in intro, we have wiki history KubilayKocak |
|---|
| ====== Kernel Bug Report Triaging Guide ====== | ====== Kernel Bug Report Triaging Guide ====== |
| Author: RobertWatson | |
| |
| Kernel bug reports fall into several classes: | Kernel bug reports fall into several classes: |
| ===== Not a bug ===== | ===== Not a bug ===== |
| |
| Sometimes kernel bug reports come from a user or documentation failure -- perhaps the feature doesn't in fact work the way the user thinks, perhaps because they documentation is wrong, or perhaps because the user is confused. It makes sense, when looking at a kernel bug report, to keep an open mind about what the source of the problem is, and confirm that the feature is intended to work the way the user expects. | Sometimes kernel bug reports come from a user or documentation failure -- perhaps the feature doesn't in fact work the way the user thinks, perhaps because the documentation is wrong, or perhaps because the user is confused. It makes sense, when looking at a kernel bug report, to keep an open mind about what the source of the problem is, and confirm that the feature is intended to work the way the user expects. |
| |
| ===== Kernel panic ===== | ===== Kernel panic ===== |
| Often we receive reports of performance problems using a microbenchmark tool that don't actually correspond to real-world performance problems. A few classic examples of this to illustrate the point: | Often we receive reports of performance problems using a microbenchmark tool that don't actually correspond to real-world performance problems. A few classic examples of this to illustrate the point: |
| |
| - bsdtar reading data from a hard disk and writing to /dev/null more slowly than gnutar. It turns out gnutar optimizes writing tarballs to /dev/null by not calling the write() system call on the data, undoubtably to help gnutar developers measure the internal performance of gnutar rather than the performance of /dev/null. As a result, bsdtar "benchmarks" much more slowly than gnutar, but might well perform fine in practice with a real workload--for example, writing to a tarball in a file system. | - bsdtar reading data from a hard disk and writing to /dev/null more slowly than gnutar. It turns out gnutar optimizes writing tarballs to /dev/null by not calling the write() system call on the data, undoubtly to help gnutar developers measure the internal performance of gnutar rather than the performance of /dev/null. As a result, bsdtar "benchmarks" much more slowly than gnutar, but might well perform fine in practice with a real workload -- for example, writing to a tarball in a file system. |
| |
| - There is significant variation in the performance of a disk based on where on the disk you are writing. The outside of a disk spins at a higher speed, and more data can be fit on it contigously, so it performs better. If someone installs two versions of %%FreeBSD%% on the same hard disk using two different disk partitions, one will inevitably be closer to the edge of the disk than the other. If swap or a file system is part of the performance measurement, than the version closer to the edge may perform better because the hardware it's running on is simply faster, even though it appears to the end-user as though there's no configuration difference. | - There is significant variation in the performance of a disk based on where on the disk you are writing. The outside of a disk spins at a higher speed, and more data can be fit on it contigously, so it performs better. If someone installs two versions of %%FreeBSD%% on the same hard disk using two different disk partitions, one will inevitably be closer to the edge of the disk than the other. If swap or a file system is part of the performance measurement, than the version closer to the edge may perform better because the hardware it's running on is simply faster, even though it appears to the end-user as though there's no configuration difference. |
| ===== References ===== | ===== References ===== |
| |
| [http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug.html Kernel Debugging Guide ] | [[https://docs.freebsd.org/en/books/developers-handbook/kerneldebug/|FreeBSD Developer Handbook: Kernel Debugging Guide]] |
| | |
| | ---- |
| | |
| | {{tag>HowTo}} |
| | {{tag>Stale}} |
| | {{tag>NeedsContent}} |
| |