vm_page(9): new man page

[mhorne]

Summary

The primary intent is to introduce a landing page which can link to
existing vm_page_** sub-pages, or other related content. It also
provides a suitable place to expand on key fields in the structure, or
concepts relating to VM pages in general.

Provide a (brief) high-level description of the vm_page_t structure and
its role within the virtual memory system, and a couple other scattered
details.

[kib]

vm_page's are fictitious or not, and managed or not.

Non-fictitious pages represent a frame of the normal physical memory, that is usable for normal memory purposes. Fictitious pages are typically used to provide VM code with a way to handle some specific physical addresses that could be usefully mapped, or otherwise handled by VM code, but are not backed by plain RAM. Good example are the device register's mapping.

Managed pages are normally managed by VM, in the sense that they are backed by some object (file, anon, etc) and VM manages it content, by e.g. writing page data out to reuse the page on low memory condition, or reading it to instantiate specific named page on page fault. This means that managed page may be repurposed at any time. For managed pages, VM tracks accessed and dirty status. Managed pages belong to some object (queue). If not wired, they are linked into some page queue, like active/inactive/laundry.

Curiously, there are managed fictitious pages (my sin), typically used for GPU memory management.

Non-fictitious non-managed pages are often used for specific kernel needs, e.g. page tables pages are such, with wired count used in non-standard way.

There is per-page lock called 'busy'. Describing it in full details is quite hard, and probably belongs to vm_page_*busy(9).

share/man/man9/vm_page.9

27

it is actually a representation of the physical memory page, or something resembling it. Not a virtual.

48

s/will/may

[kib]

Also VM_PAGE_TO_PHYS()/VM_PHYS_TO_PAGE() should be explained.