From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 44981 invoked by alias); 17 Aug 2018 17:15:00 -0000 Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Received: (qmail 44355 invoked by uid 89); 17 Aug 2018 17:14:59 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-101.2 required=5.0 tests=AWL,BAYES_00,GOOD_FROM_CORINNA_CYGWIN,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 spammy= X-HELO: mout.kundenserver.de Received: from mout.kundenserver.de (HELO mout.kundenserver.de) (217.72.192.73) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 17 Aug 2018 17:14:58 +0000 Received: from calimero.vinschen.de ([24.134.7.25]) by mrelayeu.kundenserver.de (mreue103 [212.227.15.183]) with ESMTPSA (Nemesis) id 0LqFFo-1gLfNH34dc-00dpzq for ; Fri, 17 Aug 2018 19:14:55 +0200 Received: by calimero.vinschen.de (Postfix, from userid 500) id 04BFDA81F2F; Fri, 17 Aug 2018 19:14:55 +0200 (CEST) Date: Fri, 17 Aug 2018 18:44:00 -0000 From: Corinna Vinschen To: cygwin@cygwin.com Subject: Re: memory reported in /proc/pid/status is wrongly scaled Message-ID: <20180817171454.GV3747@calimero.vinschen.de> Reply-To: cygwin@cygwin.com Mail-Followup-To: cygwin@cygwin.com References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Yvzb+MHGXtbPBi5F" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.2 (2017-12-15) X-SW-Source: 2018-08/txt/msg00235.txt.bz2 --Yvzb+MHGXtbPBi5F Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-length: 2515 On Aug 17 16:05, Livio Bertacco wrote: > 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. >=20 > Small bash script to show the issue: > #!/bin/bash > pid=3D$$ > vmsizesplit=3D($(grep VmSize /proc/$pid/status)) > vmsize1=3D"${vmsizesplit[1]}" > echo Initial memory reported in status: $vmsize1 kB > echo Allocating a 1000 kB string (bash can use more memory) > eat=3D$(printf '%1024000s') > vmsizesplit=3D($(grep VmSize /proc/$pid/status)) > vmsize2=3D"${vmsizesplit[1]}" > echo Current memory reported in status: $vmsize2 kB > echo Difference is $[$vmsize2-$vmsize1] kB >=20 > 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 >=20 > While bash may use quite more than 1000 kb in this case, 22x times larger > doesn't seem right. >=20 > 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 in= fo > from NtQueryInformationProcess/PagefileUsage which is in bytes, then it > scales it to pages dividing by wincap.page_size: > 1515: *vmsize =3D vmc.PagefileUsage / wincap.page_size (); >=20 > 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 =3D wincap.allocation_granularity (); Looks like this is the bug. get_mem_values returns all values in multiple of OS page_size (4K), but format_process_status multiplies with allocation_granularity (64K), leading to 16 times overallocation value. The other caller of get_mem_values, format_process_statm, returns number of pages. This must be expressed in multiples of allocation_granularity since that's the virtual page_size in Cygwin. But in case of format_process_status we're looking at KB values, so patch 8a32c24a7bdb0, replaceing page_size with allocation_granularity, was incorrect. Good catch! I'll revert patch 8a32c24a7bdb0 for 2.11.0. Thanks, Corinna --=20 Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat --Yvzb+MHGXtbPBi5F Content-Type: application/pgp-signature; name="signature.asc" Content-length: 833 -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEoVYPmneWZnwT6kwF9TYGna5ET6AFAlt3Ao4ACgkQ9TYGna5E T6AJ4w/+NKxDoNcmAzxAMz4THPa1LpunyIHR65D96Q8Nj51HnQxyz6HPCLiKW5nD lKPyfmSI7Yo2mmycTJ6VzL5hap+7M4fTGfilWVdduMjKeHb7hdnOymDWtyDP6B3/ nxJx74a0XSHLAwkotpnjEEv2xiDXYbUvHUH/kyr3POUj7qNIBCpu1rwvGJVheDCE +Qdxqo+32UTvf/Qj4K/2WO0KHANZh+PIveSoxU4teRUkbuwx7gdGCmFAQPHiG6Dg EqnAlae0OYuejjEvVQx7rl8zY+7N3OHYAWxOhxBwHtHF+DuyildRkU7MWueh/eEe GkzFknf4+czK72pAqNC+4F2OLEqgN8u2puUXEoGEwYkNit+1njXl/UBaq4FkBKpx 3gEs05DQlH2cZupBCNrAQS/kaZ/613O5RHERdK485AA6aQnprT20SDtHinfLVlz9 DgeRq2Nh5h28MfwlVLK7UfmjxDfWJQk/H/Jw81r+dvN06DrMlMGdTTgpkS741AFY TfdwSlX3JETCggu+CmdzI7fML5WkNj7rLBRRpDVrbBoY9CigzhYaxE97EXCiF4O5 AA6vizyq0YZeX0p/E2dElNyl+CHyhbo7BTgcZM3jSiU4KU2x61+QRGnQ6LeZcjkz /XJXO8Sv9DM7pNK+lIEdLMPm4Nk+oZBGK8iT+GNDa4UhQ6mGqKw= =S6qq -----END PGP SIGNATURE----- --Yvzb+MHGXtbPBi5F--