Hi,
Is it reasonable for a 64bit dual cpu to take 5+ seconds of processing to
cat /proc/*/statm when there is hardly more than 1gb of actual memory
space used by processes (the rest being filesystem cache)?
This makes top or anything else that uses statm, unusable.
I don't observe this behavior on a 4gb 32bit machine, with the same
working set of mysqld processes, and 3gb of filesystem cache.
# free
total used free shared buffers cached
Mem: 16278356 16264484 13872 0 85400 14819932
-/+ buffers/cache: 1359152 14919204
# ps -eda|wc
216 866 6751
# time cat /proc/*/statm
:
:
:
real 0m5.740s
user 0m0.003s
sys 0m5.521s
# uname -a
Linux silver 2.4.21-151-smp #22 SMP Mon Jan 5 21:31:07 PST 2004 x86_64 x86_64 x86_64 GNU/Linux
thanks!!
On Thu, 08 Jan 2004 13:54:58 -0500, [email protected] wrote:
> Is it reasonable for a 64bit dual cpu to take 5+ seconds of processing to
> cat /proc/*/statm when there is hardly more than 1gb of actual memory
> space used by processes (the rest being filesystem cache)?
>
> This makes top or anything else that uses statm, unusable.
Why does top still read /proc/*/statm anyway? It's not as if top actually
ever used that information (the top I looked at at the time, that is). I
submitted a patch a few months ago to remove statm because it is a)
broken and b) redundant. The message containing detailed reasoning
should be in the linux-mm archives.
Roger
On Thu, Jan 08, 2004 at 01:54:58PM -0500, [email protected] wrote:
> Is it reasonable for a 64bit dual cpu to take 5+ seconds of processing to
> cat /proc/*/statm when there is hardly more than 1gb of actual memory
> space used by processes (the rest being filesystem cache)?
Here on alpha, it takes 0.023s (0.011 sys) for 58 processes on 2.4.23.
Perhaps there's something specific to x86_64 ?
Willy
> # free
> total used free shared buffers cached
> Mem: 16278356 16264484 13872 0 85400 14819932
> -/+ buffers/cache: 1359152 14919204
>
> # ps -eda|wc
> 216 866 6751
>
> # time cat /proc/*/statm
> :
> :
> :
> real 0m5.740s
> user 0m0.003s
> sys 0m5.521s
>
> # uname -a
>
> Linux silver 2.4.21-151-smp #22 SMP Mon Jan 5 21:31:07 PST 2004 x86_64 x86_64 x86_64 GNU/Linux
>
>
> thanks!!
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
Roger Luethi writes:
> Why does top still read /proc/*/statm anyway?
> It's not as if top actually ever used that
> information (the top I looked at at the time,
> that is). I submitted a patch a few months ago
> to remove statm because it is a) broken and
> b) redundant. The message containing detailed
> reasoning should be in the linux-mm archives.
top (from procps-3.1.14 at least) only reads
the /proc/*/statm files when you activate
columns that need the statm data. Those are:
%MEM Memory usage (RES)
VIRT Virtual Image (kb)
SWAP Swapped size (kb)
RES Resident size (kb)
CODE Code size (kb)
DATA Data+Stack size (kb)
SHR Shared Mem size (kb)
nDRT Dirty Pages count
By default, some of those get displayed.
The default includes: VIRT RES SHR %MEM
To get rid of those, type this:
f o q t n enter W
(the "W" writes out a config file)
In case your top is too old for this, you
can go to http://procps.sf.net/ for a new one.