[haiku-gsoc] Re: vm_store_anonymous

  • From: Ingo Weinhold <ingo_weinhold@xxxxxx>
  • To: haiku-gsoc@xxxxxxxxxxxxx
  • Date: Mon, 26 May 2008 18:44:07 +0200

On 2008-05-26 at 14:57:40 [+0200], Zhao Shuai <upczhsh@xxxxxxx> wrote:
>  Seems that I will break the quietness :)
>  To my project, I will use a file as the swap area first.  Since it's a 
>  file, I can use the facilities provided  by the filesystem.
>  On modifying the  vm_store_anonymous_noswap, a member: struct vnode * 
>  vnode (represents the swap file) will be added to the anonymous_store 
>  stuct. And the store_anonymous operation functions will be very like those 
>  in vnode_store. Am I right?

No, the store shouldn't directly reference a swap file; in fact it could even 
use more than one swap file. The swap files should be managed by a static 
service. The stores use it to allocate swap space (i.e. actual ranges in the 
swap files), and delegate reading/writing pages to it. Initially it's fine to 
support a single swap file only, but keep in mind that we might want to 
extend it to support multiple swap files, allow adding/removing them 
dynamically, support compressing the swapped data, etc.

While this service only manages the access to the swap files and the 
allocation of memory within them, the stores need to implement the mapping 
between the cache addresses and the location in the reserved swap space.

>  I am confused by the word "commit". Does it equal "use"?

It's more like "reserving for use". The system has a certain amount of 
available memory (physical RAM and swap space), which is the maximum memory 
that can be in use at a time. For a pageable area a physical RAM page is 
allocated when a virtual page is first used. To make sure that there actually 
still is memory available at this point, memory can be reserved (committed) 
for the area earlier (usually when it is created).

For most areas their full size is reserved at creation time, but for some 
purposes it makes sense to have an over-committing area, i.e. one that 
initially reserves less memory than it could actually need later (it keeps 
reserving more on demand). E.g. a team's main thread stack area has a size of 
16 MB, of which usually only a very small part is used. Therefore we made it 

> Could anyone 
>  explain those fields in the anonymous_store struct:
>      bool        can_overcommit;

true for over-committing areas as explained above.

>      bool        has_precommitted;
>      uint8       precommitted_pages;

Relevant only when over-committing. "precommitted_pages" is the initial 
number of pages to be reserved. "has_precommitted" is set to true, when this 
number of pages has actually been reserved, which happens when the commit() 
hook is called the first time.

>      int32       guarded_size;

Used for stacks. This is a small range (usually one page) at the bottom of 
the stack which cannot be used (i.e. dereferencing a contained address will 
cause a SIGSEGV). This prevents data of an adjacent area from undetectedly 
being overwritten on stack overflow.

CU, Ingo

Other related posts: