Garrett D'Amore wrote: > Kais Belgaied wrote: > >> >>> 3. Proposed Solution >>> >>> To solve this, we propose >>> increasing this to 1/4 of available memory which is the >>> limit that in addition, agpgart imposes. >>> >>> 4. Risks; >>> >>> There is the risk that increasing this resource may allow >>> the system to allocate too much memory, which may cause >>> the Solaris kernel to run out. The kernel is probably >>> not graceful when it runs out of memory. >>> >>> If increasing this resource is not acceptable, and having >>> the user manually increase the resource is not >>> acceptable, then either Sun or the Xorg community need to >>> change the Xorg Intel graphics drivers to use less memory >>> for Sun to incorporate these drivers into the Solaris >>> product. >>> >>> Increasing this resource affects both x86 and sparc, >>> although it is only currently needed on x86. >> >> >> >> quick question: When the RAM is shared with multiple OS instances >> (virtual machines), >> is 1/4 of all available memory a reasonable limit? >> Should this be 1/4 of RAM available to the domain (host or guest) ? > > > Since we're talking about physical resources here, my gut is that this > should be of the whole platform. Generally this would be driven out of > dom0, because dom0 is the one where the graphics device is configured. > > But, I'll let the project team address it more clearly. Just my *gut* > response. >
Like the resources project.max-crypto-memory and project.max-shm-memory, project.max-device-locked-memory is based on the kernel variable availrmem_initial. Therefore, I suspect that this is 1/4 of the memory available to the guest.
