From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1b) Gecko/20020722 Description of problem: just upgraded to the newest beta release (from redhat 7.3), and 'ps' shows very abnormal memory usage, neither 'cat /proc/meminfo', 'top' or 'free' shows abnormal usage so I doubt it's a kernel-issue Version-Release number of selected component (if applicable): procps-2.0.7-21 How reproducible: Always Steps to Reproduce: type 'ps aux' Actual Results: see URL Additional info: kernel 2.4.18-7.80
I'm seeing this too (on a freshly installed Red Hat Linux Limbo (beta 2) 7.3.93). This is the output I'm seeing on Red Hat Linux release 7.3 (Valhalla) : USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root 1 0.0 1.5 1304 472 ? S 18:10 0:04 init root 2 0.0 0.0 0 0 ? SW 18:10 0:00 [keventd] and this is the output I'm seeing on Red Hat Linux release 7.3.93 (Limbo) : USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root 1 0.0 4112.5 1256 5144576 ? S 21:21 0:04 init [ root 2 0.0 0.0 0 0 ? SW 21:21 0:00 [keventd]
hmm, after some further researching I noticed it's a kernel issue, I tried with 2.4.19-pre10 and ps shows normal memory usage.
cc'ing Arjan so he can confirm/deny it being a kernel issue
it all looks ok to me here..... but I'm using 7.3 top/ps on my laptop (but limbo2 kernel)
I copied 'ps' from my 7.3 box (procps-2.0.7-12), but it still shows weird memory usage
limbo2: The ps command is horribly miscalculating memory usuage, my box right now has 256MB ram. ps aux: USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND rpc 492 0.0 2245.9 1400 5734400 ? S 17:38 0:00 portmap rpcuser 511 0.0 2316.5 1444 5914624 ? S 17:38 0:00 rpc.statd root 568 0.0 2213.8 1380 5652480 ? S 17:38 0:00 /sbin/cardmgr How can portmap be using 2000% of my memory?
Sounds like it is a kernel issue, I'll take a deeper look.
Yes. The rss field in /proc/pid/stat seems to be way off. Assigning to kernel.
*** Bug 69609 has been marked as a duplicate of this bug. ***
Changing this to blocker, since the dup was a blocker.
Finally got a handle on this one and found a fix, will be in next build
Looks pretty good with kernel-2.4.18-11.
*** Bug 70390 has been marked as a duplicate of this bug. ***