Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 30 Sep 2024 14:32:57 -0700
From:      Mark Millard <marklmi@yahoo.com>
To:        FreeBSD-STABLE Mailing List <freebsd-stable@freebsd.org>
Cc:        henrichhartzer@tuta.io
Subject:   Gradually vanishing total over time for Active+Inact+Laundry+Wired+Free as seen in top (14.1-RELEASE at least)
Message-ID:  <00911A45-1F43-4192-B2D5-74C0781EE1E3@yahoo.com>
References:  <00911A45-1F43-4192-B2D5-74C0781EE1E3.ref@yahoo.com>

next in thread | previous in thread | raw e-mail | index | archive | help
This note is based on:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D280846

comments 9 and 11. (I'm not the person that reported the
issue. I do not run 14.1-RELEASE .)

Comment 9 was about duplicating a ZFS context to UFS media
and then booting that UFS media, no ZFS file systems. It
continued to have the property that
Active+Inact+Laundry+Wired+Free decreased over time. It
turned out zfs_enable=3D"YES" had been left in place so that
ZFS was loaded but otherwise unused. Reported after some
use was (for a system with 8 GiBytes of RAM):

QUOTE [of text from top, other than the "(empty . . .)" note]
Mem: 28M Active, 76M Inact, 76M Laundry, 1464M Wired, 642M Buf, 369M =
Free
ARC: (empty, of course)
END QUOTE

Comment 11 was about then doing a "kldunload zfs.ko". That
resulted in (shown by another run of top):

QUOTE
Mem: 1536M Active, 1590M Inact, 306M Laundry, 1371M Wired, 603M Buf, =
221M Free
END QUOTE

(No ARC, as expected.)

So it appears that zfs.ko being loaded was sufficient for
memory to gradually land in (effectively) a "Mem:" category
that top does not report. (Possibly the system does not
report/track more generally?)

But: 1536+1590+306+1371+221 =3D=3D 5024

So it still does not total close to 8192 .


=3D=3D=3D
Mark Millard
marklmi at yahoo.com




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?00911A45-1F43-4192-B2D5-74C0781EE1E3>