Describe FreeBSD's virtual memory in memory(7)

[0mp]

Summary

Describe FreeBSD's virtual memory in memory(7)

This manual page is based on the Memory article
from our wiki: https://wiki.freebsd.org/action/recall/Memory

Test Plan

igor, mandoc

[bcr]

First of all: big thanks for creating this man page. I think it is good to have for non-developers and eventually moving the info out of the wiki into a man page.

I'd like to add a few more people (i.e. the ones who edited that wiki page) to get more technical review. I'm also adding John Baldwin who did the tech review for the "Absolute FreeBSD 3rd edition" book, since there are a couple of places where memory is described in lay-mans terms (i.e. the top section). Together with the others, we could fill in some gaps that might be there or add some more explanations when needed.

share/man/man7/memory.7

36

s/for non-developer audience/for a non-developer audience/

115

"Scans check" sounds wrong here (it's from the original). I think it should just be "check" or even "checks" since the scan is appearing again at the end of the sentence.

[0mp]

• Break long lines.
• Fix some grammar mistakes reported by @bcr.

[danfe]

Thanks for doing this, greatly appreciated! May I also suggest we add how do FreeBSD memory terms correlate and/or can be translated for those coming from GNU/Linux (their top(1) reports total, used, free, and buffers) or Windows environments (reserved vs. committed, see this question). This would make porting software that wants to obtain memory status much easier.

[0mp]

In D18768#415653, @danfe wrote:

Thanks for doing this, greatly appreciated! May I also suggest we add how do FreeBSD memory terms correlate and/or can be translated for those coming from GNU/Linux (their top(1) reports total, used, free, and buffers) or Windows environments (reserved vs. committed, see this question). This would make porting software that wants to obtain memory status much easier.

Great idea. I think we can work on it in a separate revision to stay focused.

[kib]

share/man/man7/memory.7

82

This is true for ZFS, but false for filesystems using buffer cache, i.e. for all non-pseudo filesystems, and even for tmpfs.

Buffer cache is for VMIO buffers is fully merged with the VM managed pages handling, VMIO buffers are only headers which point to an array of the backing VM pages for data. This is known as coherent buffer cache, and is the mechanism that ensures that read(2) and mmaped regions consistently see same data. All VMIO buffer' pages are wired.

89

Per above, memory is not evicted from buffer cache, rather when a VMIO buffer is reclaimed, the pages are unwired, and if no longer wired, put at the end of inactive queue. [It is more complicated, look at vfs_vmio_unwire()]

93

'belonging to page queues' is not correct. Managed pages are clean or dirty. For instance, managed wired page does not belong (logically) to any queue, but its dirty state is managed by VM.

Managed pages are exactly the kind of pages that are tracked by VM and can be paged out. They could be on queue or wired.

139

Unreferenced in which sense ? If you mean reference as in PG_A/PGA_REFERENCED/act_count, then it is irrelevant, clean page can be freed. If you mean something along lines of busy/hold/wired, then it would be better spelled explicitly, because otherwise even people who know our VM stop there.

169

There you clearly use 'referenced' as PG_A.

195

I do not think that we technically wire kernel text, we did not even allocated initialized vm_pages for text until recently. I believe. But the more important point is that there are a lot of allocations where memory pages are not wired but still fall into the category of being owned by some kernel subsystem. It might even represent substantial amount of the kernel memory usage.