| Summary: | top with a RH6 .toprc displays very strange processes | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Berkley Shands <bshands> |
| Component: | procps-ng | Assignee: | Jaromír Cápík <jcapik> |
| Status: | CLOSED NOTABUG | QA Contact: | BaseOS QE - Apps <qe-baseos-apps> |
| Severity: | low | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 7.0 | CC: | bshands, lmiksik, ovasik |
| Target Milestone: | rc | Keywords: | Rebase, Regression, Upstream |
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Rebase: Bug Fixes and Enhancements | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2014-09-02 13:43:24 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
This request was not resolved in time for the current release. Red Hat invites you to ask your support representative to propose this request, if still desired, for consideration in the next release of Red Hat Enterprise Linux. Hello Berkley.
Sorry for the late response.
Please, read the following answer from Jim Warner (author of the new 'top'):
----------------------------------------------------------------------------
I believe there are two separate issues here, both of which represent 'ng' changes over Berkley’s old 3.2.8 top.
*** Threads mode ( 'H' toggle)
Threads mode used to be preserved in the rcfile. Unfortunately, it was associated with the 'current' window. That would produce the following aberration if multiple windows were being shown:
. an 'H' was acknowledged and applied to all visible windows
. keying 'a' or 'w' would silently turn it off
. then keying 'H' would turn it back on, but the user expected off
I always thought of this mode as more of a gimmick than a useful provision. Why one would clutter up the display with repetitive (sometimes misleading), data is a mystery. This was especially true prior to the introduction of vertical scrolling. And before 'Threads' replaced 'Tasks' in the Summary Area, the only way to know which mode was active was to key 'H' for the confirmation message, then key it again to restore that mode.
Under procps-ng this mode is no longer window based nor is it preserved in the rcfile. It is easy, however, to know which mode is active providing the Task/Cpu states toggle ('t') is on.
*** Idle mode ('i' toggle)
This mode now includes all tasks that have used some CPU since the last update. Previously, only tasks in the 'R' (running) and 'D' (uninterruptible sleep) states were shown. That, in turn, depended whimsically on the state at the moment their particular proc_t was filled.
Thus, 'ng' top tends to show more tasks than old top, excluding only tasks that were truly idle during the prior interval. What Berkley sees as the "random selection of 16 threads" are actually tasks that have some %CPU reported. I seriously doubt that old top would have come anywhere close to showing 32 tasks under the rcfile he provided.
Both 'H' and 'i' are properly represented in the current man document and they do differ from their 3.2.8 counterparts.
-----------------------------------------------------------------------
According to the Jim's answer, it's an expected change. Please, let me know whether you have any questions or objections. If you have any proposals, maybe you could communicate with Jim directly on the procps-ng mailing list (procps) where everyone from the upstream could join the discussion.
Please, let me know whether you're ok with closing this report or whether we should discuss the topic on the ML first and wait for more answers from Jim.
Thanks in advance.
Regards,
Jaromir.
I'm fine with the explanation. I'll just have to figure out how to deal with that, and with 120+ core machines :-) thanks! Berkley Thank you, Berkley. I'm closing this as NOTABUG then. Enjoy the day. Regards, Jaromir. |
Description of problem: Using this .toprc, which works just fine under RH 6.* RCfile for "top with windows" # shameless braggin' Id:a, Mode_altscr=0, Mode_irixps=1, Delay_time=3.000, Curwin=0 Def fieldscur=AEHIOQTWKNMbcdfgJplrsuvyzX winflags=95513, sortindx=10, maxtasks=0 summclr=1, msgsclr=1, headclr=3, taskclr=1 Job fieldscur=ABcefgjlrstuvyzMKNHIWOPQDX winflags=62777, sortindx=0, maxtasks=0 summclr=6, msgsclr=6, headclr=7, taskclr=6 Mem fieldscur=ANOPQRSTUVbcdefgjlmyzWHIKX winflags=62777, sortindx=13, maxtasks=0 summclr=5, msgsclr=5, headclr=4, taskclr=5 Usr fieldscur=ABDECGfhijlopqrstuvyzMKNWX winflags=62777, sortindx=4, maxtasks=0 summclr=3, msgsclr=3, headclr=2, taskclr=3 I see 1/2 of all running processes. So on a 32-core box, with all 32 cores spinning, it shows a random selection of 16 threads. Version-Release number of selected component (if applicable): rh7-beta external release How reproducible: use the above .toprc on a machine with a single application consuming all the cores. 1/2 of the threads will display as running. This .toprc should be the same as "top -H" with "1fj " given by keyboard. Steps to Reproduce: 1. 2. 3. Actual results: random processes seen Expected results: all 32 processes seen Additional info: Maybe this is an expected change, but it sure took a while to figure out what was wrong. This makes multiple hosts logins rather cumbersome.