Red Hat Bugzilla – Bug 1160811
pmatop display corruption
Last modified: 2015-07-29 22:23:59 EDT
Created attachment 954104 [details] pmatop random screenshot When running pmatop on a moderately busy workstation for an extended period of a few minutes, I'm seeing several kinds of display corruption. 1) Additional rows appear & disappear near the CPU row temporarily duplicating "cpu" information briefly; when the rows disappear, the last rows (disk info lines) are left on the screen (now duplicated). 2) Disk I/O is not attributed correctly. While doing a backup, comparing iostat -m and pmatop values, there is little correspondence. (Attaching screen shots.) Plus even with a fresh ^L screen-refresh, the number of rows with MBr/s stats is fewer than the number of rows with busy/etc. stats.
Created attachment 954105 [details] concurrent iostat screenshot
Created attachment 961338 [details] proposed pmatop patch
I haven't yet duplicated the exact situation but I noticed this: Enforce screen width for pmatop. * pmatop.py (StandardOutput): Remember the window width... (addstr): ...and check we don't write beyond it. (timeout): Sleep for piped stdout (_Options): Override -L N with that change I ran this: atop 5 8 |& /usr/bin/grep 'DSK\|LVM' >| /tmp/,atop & pmatop.py 5 8 |& /usr/bin/grep 'DSK\|LVM' >| /tmp/,pmatop & and the results were quite close: atop LVM | yong-lv_work | busy 1% | read 0 | write 3 | avio 21.3 ms | DSK | sda | busy 1% | read 0 | write 3 | avio 21.3 ms | LVM | yong-lv_home | busy 2% | read 0 | write 13 | avio 8.46 ms | LVM | yong-lv_work | busy 0% | read 0 | write 1 | avio 0.00 ms | DSK | sda | busy 2% | read 0 | write 8 | avio 13.8 ms | pmatop LVM | yong-lv_work | | read 0 | write 3 | DSK | sda | busy 1% | read 0 | write 3 | avio 21 ms | LVM | yong-lv_work | | read 0 | write 1 | LVM | yong-lv_home | | read 0 | write 13 | DSK | sda | busy 2% | read 0 | write 8 | avio 14 ms |
The new code does not correct the original repot of duplicated lines. Here's a possible way to reproduce it. Start pmatop on a nice big xterm, say 132x44, on a fairly idle SMP box. Once pmatop has started drawing the text, run a couple of cpu-sucking tasks in the background. You will notice more "cpu | ..." lines coming onto the pmatop screen, with different clock frequencies, idle%, etc, pushing the disks down. Stop the cpu hogs. Notice the disk bits left abandoned at the bottom. Maybe it's just a matter of clear-screen()ing when dynamic-row type data changes cardinality.
This bug appears to have been reported against 'rawhide' during the Fedora 22 development cycle. Changing version to '22'. More information and reason for this action is here: https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora22
Resolved in pcp-3.10.5.