On 2018-Apr-4, at 10:16 AM, Andriy Gapon <avg at FreeBSD.org> wrote: > On 01/04/2018 05:31, Mark Millard wrote: >> I have a hypothesis for part of what top is >> counting in the process/thread SWAP column >> that might not be what one would expect. >> >> It appears to me that vnode-backed pages are >> being re-classfied sometimes for inactive >> processes, and this classification leads to >> top classifying the pages as not-resident >> but swapped (in that a "VN PAGER in" would >> be required, in systat -vmstat terms). > > Not sure. > To me it seems that top just uses wrong statistics to calculate the value. > > /* swap usage */ > #define ki_swap(kip) \ > ((kip)->ki_swrss > (kip)->ki_rssize ? (kip)->ki_swrss - (kip)->ki_rssize : 0) > > ki_rssize is the resident size of a process. > ki_swrss is resident set size before last swap. > > Their difference is... exactly what? > I cannot even meaningfully describe this value. > But it is certainly _not_ the current swap utilization by the process. > > Here is my attempt at obtaining a more reasonable approximation of the. process > swap use. But it is still wildly inaccurate. > > . . . If I get time this weekend, I'll try the patch. Thanks. I've classically seen things like (picking on java here): (no patch yet, so SWAP 0K shows) PID USERNAME THR PRI NICE SIZE RES SWAP STATE C TIME CPU COMMAND 78694 root 44 52 0 14779M 92720K 0K uwait 22 0:06 9.91% [java] when Swap: . . . 0 Used . . . (or some figure much smaller than SIZE-RES) showed. (SIZE is ki_size and RES is ki_rssize as I remember.) It suggests some form of reserved-but-not-allocated contribution to ki_size (SIZE), space not resident nor swapped out to a swap partition. Possibly vnode-backed (potential "VN PAGER in and out" contributions instead of "SWAP PAGER" ones, in systat -vmstat terms)? Are such cases examples of what you were counting as "wildly inaccurate"? Or do you count vnode-backed but not resident as perfectly good examples of SWAP in use? === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)Received on Thu Apr 05 2018 - 00:03:56 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:15 UTC