﻿id	summary	reporter	owner	description	type	status	component	version	resolution	keywords	cc	guest	host
10600	vbi_internal_alloc() should not call contig_alloc() for large allocations => Fixed in SVN	blakej		"A user of VirtualBox 4.1.16, with Solaris s11u1_16 as the host, commented
that he was seeing ""virtualbox's guru-meditation-screen-of-death due to not
being able to allocate and lock memory [...] even though plenty of memory
is available.""  The relevant comment from his logfile was:

    PGMR3PhysAllocateLargePage: allocating large pages takes too long
        (last attempt 8462 ms; nr of timeouts 1); DISABLE

I asked him to look into what VirtualBox was doing when it generated that
error message.  He found that it was in the vbox driver, making a call from
vbi_internal_alloc() -> contig_alloc() -> page_create_io() -> delay().

Further investigation showed that vbi_internal_alloc() was being called
with a size of 2MB, an alignment of 2MB, a high-address limitation of
2^64^ - 1 (i.e. no limitation), and a request for contiguity.  In other
words, it just wanted a single large page.

Looking at the VBox 4.1.16 source, vbi_internal_alloc() calls
contig_alloc() to get this page.  As it turns out, contig_alloc() is
just about the slowest imaginable way to allocate a single large page --
it assumes that it needs to respect the rest of the ddi_dma_attr_t,
and it doesn't assume that it's nicely page-aligned, so it may end up
trawling through huge amounts of the system's memory trying to stitch
together a valid region for the caller.

If you would like information on a better approach for doing this,
please contact me directly -- my email is blake.a.jones at oracle.com.
(I am the technical lead for the VM2 project in Solaris.)  I expect
that a different approach might go 100x faster.

"	defect	closed	other	VirtualBox 4.1.16	fixed		artem.kachitchkine@…	all	Solaris
