[haiku-gsoc] Re: vm_store_anonymous

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?
 
 
>Some more thoughts regarding the implementation... I'd strongly recommend to 
>have a look at how other systems (Linux, FreeBSD, OpenSolaris) implement swap 
>file support. I haven't done that myself yet, so I can't really say what 
>would be the best implementation. For reference I can sketch a simple one, 
>though:
>
>Each swap file is divided into allocatable units of, say, 16 pages, each 
>referenced by a handle:
>
>struct swap_file_chunk {
> swap_file_chunk* next;
> addr_t cache_offset;
>};
>
>The "next" field can be used for singly-linked lists or hash tables, 
>"cache_offset" is the cache-relative location of the virtual pages for which 
>the swap file chunk is used, when allocated. For each swap file an array of 
>swap_file_chunk structures is created when the swap file is added to the 
>system. An array index translates to a location in the swap file.
>
>The service managing the swap files maintains a free list of 
>swap_file_chunks, so that they can be quickly allocated and freed. Each store 
>maintains a hash table that maps virtual pages (or more precisely: 
>chunk-sized virtual page ranges) to allocated swap_file_chunks, so that it 
>can quickly look up swap file chunks, allocate new ones when needed, or free 
>them.
>
>Aside from details like the interaction with page writer and page daemon, 
>that's pretty much it already. But as I wrote in the beginning, I'd recommend 
>looking around first. There are probably better solutions that can be 
>borrowed.
>
>CU, Ingo
>

Other related posts: