src/usr.bin/vmstat, branch releng/12.0

Dynamically allocate IRQ ranges on x86.

2018-08-28T21:09:19Z

Previously, x86 used static ranges of IRQ values for different types of I/O interrupts. Interrupt pins on I/O APICs and 8259A PICs used IRQ values from 0 to 254. MSI interrupts used a compile-time-defined range starting at 256, and Xen event channels used a compile-time-defined range after MSI. Some recent systems have more than 255 I/O APIC interrupt pins which resulted in those IRQ values overflowing into the MSI range triggering an assertion failure. Replace statically assigned ranges with dynamic ranges. Do a single pass computing the sizes of the IRQ ranges (PICs, MSI, Xen) to determine the total number of IRQs required. Allocate the interrupt source and interrupt count arrays dynamically once this pass has completed. To minimize runtime complexity these arrays are only sized once during bootup. The PIC range is determined by the PICs present in the system. The MSI and Xen ranges continue to use a fixed size, though this does make it possible to turn the MSI range size into a tunable in the future. As a result, various places are updated to use dynamic limits instead of constants. In addition, the vmstat(8) utility has been taught to understand that some kernels may treat 'intrcnt' and 'intrnames' as pointers rather than arrays when extracting interrupt stats from a crashdump. This is determined by the presence (vs absence) of a global 'nintrcnt' symbol. This change reverts r189404 which worked around a buggy BIOS which enumerated an I/O APIC twice (using the same memory mapped address for both entries but using an IRQ base of 256 for one entry and a valid IRQ base for the second entry). Making the "base" of MSI IRQ values dynamic avoids the panic that r189404 worked around, and there may now be valid I/O APICs with an IRQ base above 256 which this workaround would incorrectly skip. If in the future the issue reported in PR 130483 reoccurs, we will have to add a pass over the I/O APIC entries in the MADT to detect duplicates using the memory mapped address and use some strategy to choose the "correct" one. While here, reserve room in intrcnts for the Hyper-V counters. PR: 229429, 130483 Reviewed by: kib, royger, cem Tested by: royger (Xen), kib (DMAR) Approved by: re (gjb) MFC after: 2 weeks Differential Revision: https://reviews.freebsd.org/D16861

Fully retire the unimplemented -t option from vmstat(8).

2018-08-20T09:29:21Z

It was #ifdef'd out in the 4.4BSD import and hasn't been re-enabled since then. Reviewed by: kib MFC after: 2 weeks Differential Revision: https://reviews.freebsd.org/D16804

vmstat(1): various nits

2018-06-13T08:52:04Z

Continue my parade on introspection tools by fixing: - failed to check for null after reallocf - avoid the comma operator - mark usage as dead - correct size of len

Temporarily widen count for interrupt rate calculations on 32-bit archs

2018-02-08T05:18:30Z

If the interrupt count is very high (greater than ~42M), notably on one-shot execution on long running systems, the intermediate multiplication step in the rate calculation will overflow the width of a 32-bit architecture long (32 bits), causing the rest of the calculation to calculate with a truncated value, and report very low rates (sometimes 0). MFC after: 2 weeks

Update various statements in vmstat(8) to match reality.

2018-01-18T19:43:02Z

- The process stats are actually thread counts rather than process counts. - Simplify various descriptions to remove mention of stats that are updated every 5 seconds (all VM related stats are now "instant", only the load average is updated every 5 seconds). - Don't make any mention of special treatment for processes that have been active in the last 20 seconds. We don't track that stat. - Rework the description of active virtual memory. Call it mapped virtual memory and explicitly point out it is not the same as the active page queue (which corresponds to "Active" in top(1)), and also hint at the possible bogusness of the value (e.g. if a process maps a single page out of a multiple GB file, the entire file's size is considered mapped). - Simplify a few descriptions that implied their output was a value per interval. All of the "rate" values are per-second rates scaled across the interval. - Update a few comments for 'struct vmtotal' along similar lines. Reported by: mwlucas (indirectly) Reviewed by: kib MFC after: 1 week Differential Revision: https://reviews.freebsd.org/D13905

vmstat(8): Hook up NetBSD tests

2018-01-11T16:04:04Z

The NetBSD tests for vmstat are basically just a smoke test, ensuring that executing `vmstat` and `vmstat -s` exit successfully. This is more than we test now, so go with it.

Re-add spaces lost in r326436.

2017-12-14T15:40:03Z

X-MFC with: r326436

vmstat: fix style(9) violations and bump WARNS.

2017-12-01T22:38:28Z

Based on the patch by: Pawel Biernacki Sponsored by: Mysterious Code Ltd. (Pawel), The FreeBSD Foundation (me) MFC after: 1 week Differential revision: https://reviews.freebsd.org/D13228

vmstat: use 64-bit counters from struct vmtotal.

2017-11-23T19:10:09Z

Consistently print counters using unsigned intmax type. Submitted by: Pawel Biernacki Sponsored by: Mysterious Code Ltd. Differential revision: https://reviews.freebsd.org/D13199

Use C standard spelling uint64_t for u_int64_t.

2017-11-23T19:06:44Z

Submitted by: Pawel Biernacki Sponsored by: Mysterious Code Ltd. X-Differential revision: https://reviews.freebsd.org/D13199