public inbox for cygwin@cygwin.com
 help / color / mirror / Atom feed
From: Livio Bertacco <lbertacco@tiscali.it>
To: cygwin@cygwin.com
Subject: memory reported in /proc/pid/status is wrongly scaled
Date: Fri, 17 Aug 2018 15:35:00 -0000	[thread overview]
Message-ID: <CAL0dvtiDxdcN2qUG2MEG0vrpkr=R2LkopK7ECV8YamWyo7K=ng@mail.gmail.com> (raw)

 Hi,
While playing with reading process memory usage in Linux and cygwin, I
found that cygwin reports too large values in /proc/self/status (in 2.10.0
and earlier).
Whenever I was allocating a few kB in my test program, the VmSize line in
/proc/self/status was growing several times faster.

Small bash script to show the issue:
#!/bin/bash
pid=$$
vmsizesplit=($(grep VmSize /proc/$pid/status))
vmsize1="${vmsizesplit[1]}"
echo Initial memory reported in status: $vmsize1 kB
echo Allocating a 1000 kB string (bash can use more memory)
eat=$(printf '%1024000s')
vmsizesplit=($(grep VmSize /proc/$pid/status))
vmsize2="${vmsizesplit[1]}"
echo Current memory reported in status: $vmsize2 kB
echo Difference is $[$vmsize2-$vmsize1] kB

Running this in cygwin on my laptop I get:
Initial memory reported in status: 84928 kB
Allocating a 1000 kB string (bash can use more memory)
Current memory reported in status: 106880 kB
Difference is 21952 kB

While bash may use quite more than 1000 kb in this case, 22x times larger
doesn't seem right.

Checking source file fhandler_process.cc, the
function format_process_status which writes the "status" proc file
retrieves memory usage via get_mem_values. Get_mem_values obtains that info
from NtQueryInformationProcess/PagefileUsage which is in bytes, then it
scales it to pages dividing by wincap.page_size:
1515: *vmsize = vmc.PagefileUsage / wincap.page_size ();

Then format_process_status scales it back, in theory to bytes, and shifts
it by 10 bits in order to print it out in kB:
1219:  unsigned page_size = wincap.allocation_granularity ();
1220:  vmsize *= page_size;

The first observation is that scaling and unscaling are using different
factors, causing the issue. Same for the other memory amounts reported in
the "status" file (VmLck, VmRSS, etc....). Memory reported in the "stat"
file seems ok, and regarding the "statm" file, I'm not really sure (since
I'm not sure about what the correct page size should be in cygwin).
A second observation is that the same struct that contains PagefileUsage
also contains PeakPagefileUsage, so it would be very easy to also add the
VmPeak line to the "status" file (as in Linux).

Regards,
Livio

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

             reply	other threads:[~2018-08-17 14:05 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-17 15:35 Livio Bertacco [this message]
2018-08-17 18:44 ` Corinna Vinschen
2018-08-17 20:36   ` Corinna Vinschen
2018-08-21 20:04 Livio Bertacco
2018-08-21 20:20 ` Corinna Vinschen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAL0dvtiDxdcN2qUG2MEG0vrpkr=R2LkopK7ECV8YamWyo7K=ng@mail.gmail.com' \
    --to=lbertacco@tiscali.it \
    --cc=cygwin@cygwin.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).