dtrace discuss - Apr 2006 - DTraceToolkit/Mem/swapinfo.d strange output

bash-3.00# Mem/swapinfo.d
RAM  _______Total  8191 Mb
RAM      Unusable     8 Mb
RAM        Kernel  1403 Mb
RAM        Locked     0 Mb
RAM          Used   535 Mb
RAM         Avail  6244 Mb

Disk _______Total   517 Mb
Disk         Used 17592186044398 Mb
Disk        Avail   535 Mb

Swap _______Total  6275 Mb
Swap         Used   517 Mb
Swap        Avail  5757 Mb
Swap    (Minfree)  1022 Mb
 
 
This message posted from opensolaris.org

Hi,

Are you thinking about Disk Used 17592186044398 Mb ?

Hm, this is the part of the D code which does compute that:

        this->disk_used  = `k_anoninfo.ani_phys_resv - this->ram_used >
0 ?
            `k_anoninfo.ani_phys_resv - this->ram_used : 0;
and

        this->disk_used *= `_pagesize;  this->disk_used /= 1048576;


where k_anoninfo.ani_phys_resv is the no. of physical reserved slots part of the
anonymous memory accounting defined in vm/anon.h:

struct k_anoninfo {
        pgcnt_t ani_max;        /* total reservable slots on phys */
                                        /* (disk) swap */
        pgcnt_t ani_free;       /* # of unallocated phys and mem slots */
        pgcnt_t ani_phys_resv;  /* # of reserved phys (disk) slots */
        pgcnt_t ani_mem_resv;   /* # of reserved mem slots */
        pgcnt_t ani_locked_swap; /* # of swap slots locked in reserved */
                                /* mem swap */
};

Is this a bug ? Im looking to ''this->ram_used'' which is
defined in pages, isn''t it ? But is the
''ani_phys_resv'' defined in pages too ?

stefan
 
 
This message posted from opensolaris.org

Stefan Parvu wrote:
[snip]
> struct k_anoninfo {
>         pgcnt_t ani_max;        /* total reservable slots on phys */
>                                         /* (disk) swap */
>         pgcnt_t ani_free;       /* # of unallocated phys and mem slots */
>         pgcnt_t ani_phys_resv;  /* # of reserved phys (disk) slots */
>         pgcnt_t ani_mem_resv;   /* # of reserved mem slots */
>         pgcnt_t ani_locked_swap; /* # of swap slots locked in reserved */
>                                 /* mem swap */
> };
> 
> Is this a bug ? Im looking to ''this->ram_used'' which
is defined in pages, isn''t it ? But is the
''ani_phys_resv'' defined in pages too ?
Yes. Though, ani_phys_resv doesn''t tell you much of anything,
it''s just
reserved disk swap space as opposed to disk swap space actually in use to 
hold stuff. If you want to see how much of the swap is reserved that would 
be `k_anoninfo.ani_max - `k_anoninfo.ani_phys_resv.

And no, if this is confusing you aren''t alone. I''ve been
working in the
Solaris VM system for five and a half years now, and this stuff *still* 
makes my head spin. I can''t wait to take a cutting torch to all of the 
swapfs code...

- Eric

G''Day Folks,

Firstly - swapinfo in already on my ToDo list to revist. I first wrote it
in 2004 (in Perl) without access to the Solaris source! What I did use is
listed in "SEE ALSO". That Perl version of swapinfo is online at,
http://www.brendangregg.com/k9toolkit.html, with a note in red to say that
it is under construction. (I actually added that note to the DTrace
version a few days ago).

So it is a known bug, and it will get fixed.

On Sat, 22 Apr 2006, Eric Lowe wrote:
> Stefan Parvu wrote:
> [snip]
> > struct k_anoninfo {
> >         pgcnt_t ani_max;        /* total reservable slots on phys */
> >                                         /* (disk) swap */
> >         pgcnt_t ani_free;       /* # of unallocated phys and mem slots
*/
> >         pgcnt_t ani_phys_resv;  /* # of reserved phys (disk) slots */
> >         pgcnt_t ani_mem_resv;   /* # of reserved mem slots */
> >         pgcnt_t ani_locked_swap; /* # of swap slots locked in reserved
*/
> >                                 /* mem swap */
> > };
> >
> > Is this a bug ? Im looking to ''this->ram_used''
which is defined in
> > pages, isn''t it ? But is the
''ani_phys_resv'' defined in pages too ?
>
> Yes. Though, ani_phys_resv doesn''t tell you much of anything,
it''s just
> reserved disk swap space as opposed to disk swap space actually in use to
> hold stuff. If you want to see how much of the swap is reserved that would
> be `k_anoninfo.ani_max - `k_anoninfo.ani_phys_resv.
Here is swapinfo.d in DEBUG mode (see the source), followed by swap -l,

   # ./swapinfo.d
   DEBUG   availrmem   377 MB
   DEBUG     ani_max  1023 MB
   DEBUG ani_phys_re   623 MB
   DEBUG  ani_mem_re     0 MB
   DEBUG  ani_locked     0 MB
   DEBUG     reserve     4 MB

   RAM  _______Total   511 MB
   RAM      Unusable     8 MB
   RAM        Kernel   125 MB
   RAM        Locked     0 MB
   RAM          Used   248 MB
   RAM         Avail   129 MB

   Disk _______Total  1023 MB
   Disk         Used   375 MB
   Disk        Avail   648 MB

   Swap _______Total  1338 MB
   Swap         Used   623 MB
   Swap        Avail   715 MB
   Swap    (Minfree)    62 MB

   Now run other commands for confirmation.
   ^Z
   [1]+  Stopped                 ./swapinfo.d
   # swap -l
   swapfile             dev  swaplo blocks   free
   /dev/dsk/c0d0s1     102,1       8 2096632 1315664
   # echo "(2096632-1315664)/(2*1024)" | bc
   381

Ok, so "swap -l" reports that 381 Mbytes are used (free == not
allocated).
swapinfo.d is reporting that 375 Mbytes are used - so they are fairly
close.

Hrm, I''m actually dissapointed - I spent weeks wrestling with the
original version so that the numbers were closer than that...
Now running the original version,

   $ swapinfo
   RAM  _____Total   511.6 Mb
   RAM    Unusable     8.0 Mb
   RAM      Kernel   125.6 Mb
   RAM      Locked     0.0 Mb
   RAM        Used   249.5 Mb
   RAM       Avail   128.4 Mb

   Disk _____Total  1023.7 Mb
   Disk      Alloc   381.3 Mb
   Disk       Free   642.4 Mb

   Swap _____Total  1338.8 Mb
   Swap      Alloc   591.9 Mb
   Swap    Unalloc    32.8 Mb
   Swap      Avail   714.1 Mb
   Swap  (MinFree)    62.9 Mb

381 == 381.3! :-)

It''s no fault of DTrace - I''ve just spent more time on the
original
version. The DTrace version should be more accurate, as it has access to
more data  structures.

I know the calculations I used didn''t look right (based on the comments
in the header files) - but they stood up to testing (until recently). I
had figured out reasons for these algorithms, but they escape me at the
moment.
> And no, if this is confusing you aren''t alone. I''ve been
working in the
> Solaris VM system for five and a half years now, and this stuff *still*
> makes my head spin. I can''t wait to take a cutting torch to all of
the
> swapfs code...
Yep. I had written kstat tools before and figured this would take a night
or two. A month later, I was still trying to get the numbers to add up.
By that point my head was really spinning, and I had started drawing
diagrams like that on the K9toolkit website to make sense of it all.
Googling for many of the k_anoninfo components had zero hits.

I''ve been reading the Solaris source for 10 months now, but
haven''t
visited swapinfo.d yet, as I know it will take a huge slab of time to
pick through (and more in testing). I will get there.

Richard wrote some good stuff on this for Solaris Internals 2nd ed -
which helps a lot. :)

...

Maybe the swapfs code can be improved as part of swap-sets... :)

cheers,

Brendan