[haiku-gsoc] Re: vm_store_anonymous

On 2008-06-20 at 16:50:39 [+0200], Zhao Shuai <upczhsh@xxxxxxx> wrote:
> I spent another few days on the FreeBSD swap file implementation, but still 
> can
> not get a total undertanding... :(
>  
> So I decide to use your scheme, which is very similar to FreeBSD.
>  
> One thing I don't understand: why use a chunk as an allocation unit? If we 
> swap
> only 4 or 5 pages out, we had to allocate 16 pages. Is that a waste of 
> space?

Yep. The intention was to avoid swap space fragmentation and to have only 
minimal memory (RAM) overhead.

Anyway, I had a look at the FreeBSD VM implementation. It is indeed quite 
similar to Haiku's. The swap support works like this:

* For each swap device a bitmap radix tree manages swap space allocations.

* Swap space allocation happens in round-robin manner from the swap devices.

* Usually more than one page is swapped out at a time. It is attempted to 
allocate a contiguous range in the swap space for them. If that fails, the 
range is broken down.

* The page -> swap address mapping happens via a global hash table. It 
actually maps (vm_object_t, page cluster base index) pairs to swblocks. An 
swblock contains the swap addresses of 16 consecutive pages (consecutive in 
the vm_object_t (the equivalent of Haiku's vm_cache + vm_store)).

* swblocks are allocated when needed, from a special zone (supposedly 
something like a pre-allocated object cache).

I also had a quick look at the OpenSolaris VM implementation, which is quite 
different to Haiku's. They don't seem to use layered VM objects. Instead 
segments (pretty much the equivalent to Haiku areas) have a function vector 
depending on their type. For each page of anonymous memory an anon structure 
is created on demand (i.e. when it is paged out), which maps the page to its 
swap space location (vnode + offset). The anon structures are put into a 
global hash table. Per swap area (file/device) a flat bitmap is maintained 
for swap space allocation.

So in fact the FreeBSD and OpenSolaris swap implementations are not 
unsimilar, though the FreeBSD one looks a bit better to me. It wastes less 
memory for the page -> swap space mappings and also the swap space allocation 
management seems more intelligent (bitmap radix tree vs. flat bitmap). Both 
implementations use round-robin for swap space allocation, but OpenSolaris 
switches the swap area only every 1 MB. The global swap space mappings hash 
table is protected by 64 mutexes in OpenSolaries (effectively slicing the 
table), likely to reduce lock contention.

For Haiku I'd go with FreeBSD's model, though start with some 
simplifications, that can be optimized later: Like using a bitmap per swap 
device instead of a radix tree, and paging out/in only single pages (though 
have in mind that this needs to be extended).

CU, Ingo

Other related posts: