[haiku-gsoc] Re: vm_store_anonymous
- From: "Zhao Shuai" <upczhsh@xxxxxxx>
- To: haiku-gsoc@xxxxxxxxxxxxx
- Date: Fri, 20 Jun 2008 22:50:39 +0800 (CST)
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:
