:Going through the 4.4 BSD book, I learnt that the purpose of the pv_table
:is to be able to locate all the mappings to a given physical page.
:
:However, comparing this to the Linux approach, which chains vm_area_struct
:(analogous to vm_map_entry in FreeBSD) together to locate the shared
:mappings, it appears to me that the Linux approach is more space efficient.
:
:So why not eliminate pv_table and chain vm_map_entries together to represent
:the sharing information ?
:
: -Arun
The primary difference between the FreeBSD method and the Linux method
is that the linux method takes a heavy toll in cpu by requiring a test
for the page in every VM map that *might* contain that page. Since most
pages in the vast majority of objects are not mapped, the FreeBSD way of
doing things is typically O(1) while the linux way is O(N). This may not
seem expensive, but consider what happens when you have to manipulate
a *range* of pages within an object. The FreeBSD way becomes O(N) and the
linux way becomes O(N^2).
( Now I'm simplifying... the FreeBSD way isn't *precisely* O(N), but
neither is it anywhere near O(N^2) ).
Another big difference between Linux and FreeBSD is with how page tables
are maintained. Under Linux, page-tables are SWAP-BACKED. This is
because Linux maintains considerable state in its page tables which cannot
be recreated from other sources. Under FreeBSD, page-tables are
THROW-AWAY, which means that FreeBSD can throw away elements in page
tables and even whole page tables at very low cost.
The FreeBSD way makes it fairly trivial for the VM system to manage
pages, especially when figuring out the type of activity being performed
on pages. This gives FreeBSD a significant advantage in determining which
pages are good candidates to swap out or throw away. The equivalent
operation under Linux is a very expensive scan of all page tables in all
processes.
-Matt
Matthew Dillon
<[email protected]>
To Unsubscribe: send mail to [email protected]
with "unsubscribe freebsd-hackers" in the body of the message
