Re: kern/45539: add support for getrusage(2) memory size statistics

["Greg A. Woods" <woods%planix.ca@localhost>]

The following reply was made to PR kern/45539; it has been noted by GNATS.

From: "Greg A. Woods" <woods%planix.ca@localhost>
To: NetBSD GNATS <gnats-bugs%NetBSD.org@localhost>
Cc: 
Subject: Re: kern/45539: add support for getrusage(2) memory size statistics
Date: Fri, 28 Oct 2011 19:38:26 -0700

 --pgp-sign-Multipart_Fri_Oct_28_19:38:26_2011-1
 Content-Type: text/plain; charset=US-ASCII
 Content-Transfer-Encoding: quoted-printable
 
 BTW, by "tested on netbsd-5" I should say that I've successfully run a
 netbsd-5 kernel with this patch and I have seen from time(1)'s '-l'
 option that it now "does something".
 
 I don't know if the results are right -- I'm not sure they're even
 really close.  I also note that sometimes it doesn't show anything
 at all, but it seems to be on the right track.
 
 Here's an example of time(1)'s output after my tcountbits test run:
 
        75.47 real         0.32 user        75.12 sys
        204  maximum resident set size
        150  average shared memory size
        513  average unshared data size
         11  average unshared stack size
         21  page reclaims
          8  page faults
          0  swaps
          0  block input operations
          0  block output operations
          0  messages sent
          0  messages received
          0  signals received
          5  voluntary context switches
        142  involuntary context switches
 
 Note this is a static-linked binary, and here from the size(1) info it
 looks like the text size seems about right, and I guess the stack could
 be right too, but the data size seems wonky:
 
 # size ~/tmp/tcountbits
    text    data     bss     dec     hex filename
  152953    3176   15572  171701   29eb5 /root/tmp/tcountbits
 
 Hmmm.... maybe it's not wonky, as it seems that once the first set of
 results has been shown the virtual size skyrockets:
 
 # /usr/bin/time -l tmp/tcountbits -ti 1=20
 tcountbits: using CLOCK_MONOTONIC timer with resolution: 0 s, 279 ns
 tcountbits: now running each algorithm for 1000000 iterations....
 ^Z[1] + Stopped              /usr/bin/time -l tmp/tcountbits -ti 1=20
 # ps -lp 376
 UID PID PPID CPU PRI NI  VSZ RSS WCHAN  STAT TTY      TIME COMMAND
   0 376  375   0  43  0  184 192 -      T    tty00 0:01.23 tmp/tcountbits -=
 ti 1
 # fg
 /usr/bin/time -l tmp/tcountbits -ti 1=20
             time() =3D -0.0004 us/c user,  8.8335 us/c sys, 39.5177 us/c wa=
 it, 48.3507 us/c wall
 ^Z[1] + Stopped              /usr/bin/time -l tmp/tcountbits -ti 1=20
 # ps -lp 376 =20
 UID PID PPID  CPU PRI NI  VSZ RSS WCHAN STAT TTY      TIME COMMAND
   0 376  375 2998  42  0 1772 212 -     T    tty00 0:11.49 tmp/tcountbits -=
 ti 1
 
 
 The numbers from getrusage() are not quite matching what I see from
 ps(1) either, but they're very close -- perhaps the averaging explains
 the differences.
 
 --=20
                                                Greg A. Woods
                                                Planix, Inc.
 
 <woods%planix.com@localhost>       +1 250 762-7675        
http://www.planix.com/
 
 --pgp-sign-Multipart_Fri_Oct_28_19:38:26_2011-1
 Content-Type: application/pgp-signature
 Content-Transfer-Encoding: 7bit
 
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1.4.9 (NetBSD)
 
 iD8DBQBOq2ciZn1xt3i/9H8RAmaEAKDGlLNnj577PVcr9IDkpYkqZpe6bACcCvSD
 bRVWjR8IyYyYAFrrp813NKQ=
 =bQW2
 -----END PGP SIGNATURE-----
 
 --pgp-sign-Multipart_Fri_Oct_28_19:38:26_2011-1--