[haiku-development] Re: GSoc Swap file Project
- From: "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Sat, 05 Apr 2008 10:56:54 +0200 CEST
Hi Zhao,
赵帅 <upczhsh@xxxxxxx> wrote:
> I am interested in the GSoc Haiku project - Implement paging(swap
> file) support and have
> submitted my proposal.
Thanks, just read it through!
> I have read the vm source code and found that most facilities
> supporting the paging system
> have been ready. What needs to do is to implement a module that
> writes the modified pages
> back to their backing store (currently the algorithm only steals the
> pages and put it to the dirty
> page queue).
Actually, that's all there, too. While it might not be entirely clear,
the page writer lives in vm_page.cpp (called page_writer()).
You are right that the vm_store_anonymous_noswap module would need to
be replaced by the vm_store_anonymous module to enable swapping. All
userland memory should use the latter, while the kernel (and everything
that specified B_LAZY_LOCK/B_FULL_LOCK when creating the area (see
http://www.haiku-os.org/legacy-docs/bebook/TheKernelKit_Areas_Overview.html
for more detail)).
So the task mainly includes writing a vm_store that supports one or
more swap files (all swap files should be managed by a single vm_store
module and be seen as a contiguous space). Of course, you might want to
bind a specific vm_store object to only a single file, but that's up to
you.
The algorithm should try to put the pages of a single vm_cache object
close, so that it can be read back fast (the vm_page::cache_offset
field will be handy here, also to determine the location of the page in
the swap file).
If you have lots of time left (well, you never know), you could working
on refining the page daemon (ie. which pages it selects first). As a
general policy, unmapped file cache pages should be the preferred
victims over application data (the system as a whole should stay as
responsive as possible).
Alternatively, you could try to implement a mechanism to compress the
pages in the swap, allow it to hot (un)plug a swap file, etc.
> It sounds easy logically, but lots of details should be carefully
> considered . I think dealing
> with the store device is one troublesome thing, because reading/
> writing in the swap file is
> different from the regular file.
It is, but you actually don't really need to cope with that as long as
the current environment is enough for your needs (it should be, but you
will know better when you run into problems :-)).
> I was told that locking is another thing that should be paid
> attention to. Currently I don't
> have much knowledge on it.
> Can anyone give me some suggestions on it?
The lock strategies in the VM can become a bit complex due to the
memory restrictions of most code paths. Often, the only way to make
sure it'll work in low memory situations is to allocate all the memory
you'll need upfront.
Bye,
Axel.
Other related posts:
