[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: When should ralloc.c be used?

From: Jérémie Courrèges-Anglas
Subject: Re: When should ralloc.c be used?
Date: Fri, 28 Oct 2016 09:09:22 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (berkeley-unix)

Daniel Colascione <address@hidden> writes:

> address@hidden (Jérémie Courrèges-Anglas) writes:
>> Daniel Colascione <address@hidden> writes:
>>> On 10/24/2016 08:40 AM, Eli Zaretskii wrote:
>>>>> From: Stefan Monnier <address@hidden>
>>>>> Cc: address@hidden,  address@hidden
>>>>> Date: Mon, 24 Oct 2016 10:37:19 -0400
>>>>>> Using mmap has disadvantages: when you need to enlarge buffer text,
>>>>>> and that fails (because there are no more free pages/addresses after
>>>>>> the already allocated region), we need to copy buffer text to the new
>>>>>> allocation.
>>> 64-bit address spaces are *huge*. What about just making every buffer
>>> allocation 2GB long or so, marked PROT_NONE? You don't actually have to
>>> commit all that memory --- all you've done is set aside that address
>>> space.
>> IIUC you suggest relying on memory overcommit.  That doesn't sound
>> portable at all.  Not all OSes do overcommit and the ones who do
>> generally provide a way to disable it.
> You understand incorrectly. "Overcommit" is the practice of allowing an
> operating system to lie about how much memory it's guaranteed to give
> applications in the future.  We're not talking about guaranteed
> memory. We're talking about setting aside address space only, not asking
> the OS to make guarantees about future memory availability.  All major
> operating systems, even ones like Windows that don't do overcommit,
> provide ways to reserve address space without asking the OS to guarantee
> availability of memory.

Can you point at some documentation regarding those techniques?  I fail
to find one that would work on my "non-major", mostly POSIX OS.

> That said, my idea probably isn't the best --- but it doesn't rely
> on overcommit.

jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE

reply via email to

[Prev in Thread] Current Thread [Next in Thread]