[haiku-commits] Re: r36489 - in haiku/trunk: headers/private/kernel/vm src/system/kernel/vm

  • From: Ingo Weinhold <ingo_weinhold@xxxxxx>
  • To: haiku-commits@xxxxxxxxxxxxx
  • Date: Mon, 26 Apr 2010 17:59:59 +0200

On 2010-04-26 at 16:16:32 [+0200], Stephan Assmus <superstippi@xxxxxx> wrote:
> On 2010-04-26 at 15:56:09 [+0200], ingo_weinhold@xxxxxx wrote:
> > Author: bonefish
> > Date: 2010-04-26 15:56:09 +0200 (Mon, 26 Apr 2010)
> > New Revision: 36489
> > Changeset: http://dev.haiku-os.org/changeset/36489/haiku
> > 
> > Modified:
> >    haiku/trunk/headers/private/kernel/vm/vm_page.h
> >    haiku/trunk/src/system/kernel/vm/vm_page.cpp
> > Log:
> > * The "page_stats" command does now also print the longest contiguous runs
> > of
> >   free respective free and cached pages.
> > * Removed the unused vm_page_allocate_page_run_no_base().
> > * vm_page_allocate_page_run() (and allocate_page_run()):
> >   - Use vm_page_reserve_pages() instead of vm_page_try_reserve_pages(), 
> >   i.e.
> >     wait until the reservation succeeds.
> >   - Now we iterates two times through the pages to find a suitable page
> >   run. In
> >     the first iteration it only looks for free/clear pages, in the second
> >     iteration it also considers cached pages. This increases the chance of
> >     the
> >     function to succeed, when a lot of caching is going on.
> >     This reduces the amount of memory required to use the IOCache when
> >     booting
> >     off the anyboot Live CD to around 160 MB in qemu. It also seems to 
> >     work
> >     with
> >     128 MB, but the syslog indicates that some memory allocations fail,
> >     which
> >     is not exactly inspiring confidence.
> 
> As a last resort, using the IOCache could become a run-time configuration
> that depends on the amount of available memory.

That was my plan anyway. While the IOCache shouldn't add memory pressure, it 
does increase physical memory fragmentation, which makes large contiguous 
allocations more likely to fail. And since at least USB needs those ATM, some 
low memory limit is required anyway.

> On a related note, I just found out that booting a regular QEMU image with
> 128 MB RAM, launching WebPositive will fail. It could also be a result of 
> the
> library and executable "pre-caching" that Axel and I introduced for the last
> alpha.

If swapping is not enabled (respectively there's not enough space on disk), I 
wouldn't expect it to load with that little RAM. listarea for WebPositive 
shows that the mapped executable and library segments sum up to more than 48 
MB. While loading the executable that much memory will be tried to be 
committed, i.e. actually needs to be freeable by the system.

> Perhaps both problems even relate somehow, i.e. maybe using the
> IOCache at 128 MB RAM stops being a problem if the pre-caching is turned 
> off,
> which in turn is not necessary anymore when the IOCache is used.

The IOCache was only intended as a temporary solution for CDs. Maybe the code 
can be used as a base for the block cache rewrite that we would like to see 
eventually, but until then I wouldn't consider it for HDs.

CU, Ingo

Other related posts: