On 8/04/2021 2:59 pm, Helge Oldach wrote: >>>>> On Wed, Apr 07, 2021 at 10:42:57PM +0300, Andriy Gapon wrote: >>>>>> >>>>>> I regularly see that the top's memory line does not add up (and by a >>>>>> lot). >>>>>> That can be seen with vm.stats as well. >>>>>> >>>>>> For example: >>>>>> $ sysctl vm.stats | fgrep count >>>>>> vm.stats.vm.v_cache_count: 0 >>>>>> vm.stats.vm.v_user_wire_count: 3231 >>>>>> vm.stats.vm.v_laundry_count: 262058 >>>>>> vm.stats.vm.v_inactive_count: 3054178 >>>>>> vm.stats.vm.v_active_count: 621131 >>>>>> vm.stats.vm.v_wire_count: 1871176 >>>>>> vm.stats.vm.v_free_count: 187777 >>>>>> vm.stats.vm.v_page_count: 8134982 >>>>>> >>>>>> $ bc >>>>>>>>> 187777 + 1871176 + 621131 + 3054178 + 262058 >>>>>> 5996320 >>>>>>>>> 8134982 - 5996320 >>>>>> 2138662 >>>>>> >>>>>> As you can see, it's not a small number of pages either. >>>>>> Approximately 2 million pages, 8 gigabytes or 25% of the whole memory on >>>>>> this >>>>>> system. >>>>>> >>>>>> This is 47c00a9835926e96, 13.0-STABLE amd64. >>>>>> I do not think that I saw anything like that when I used (much) older >>>>>> FreeBSD. > > That sounds like PR 234559 which has an explanation. > > Kind regards > Helge >
Thanks Helge, I appreciate the pointer to understand from Mark J. in 2019 that: "Basically, we started lazily dequeuing wired pages to avoid the page queue synchronization cost incurred by frequent wirings. The result is that wired pages may temporarily be counted as active/inactive/laundry despite not being reclaimable. Maintaining the previous behaviour wrt statistics would introduce synchronization overhead that we've been trying to avoid" (#1) A minor and known counting error to avoid sync'ing overhead is fine. Ref #1: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=234559 _______________________________________________ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
