emacs-devel
[Top][All Lists]
Advanced

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

Re: When should ralloc.c be used?


From: Ken Raeburn
Subject: Re: When should ralloc.c be used?
Date: Wed, 26 Oct 2016 00:36:42 -0400

> On Oct 25, 2016, at 12:06, Eli Zaretskii <address@hidden> wrote:
> 
>> From: Ken Raeburn <address@hidden>
>> Date: Mon, 24 Oct 2016 23:12:40 -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.  This happens quite a lot when we visit a compressed
>>> buffer.  (The MS-Windows emulation of mmap in w32heap.c reserves twice
>>> the number of pages as originally requested, for that very reason.)
>> 
>> In the general case, yes.  But modern Linux kernels have an “mremap” system 
>> call which can “move” a range of pages to a portion of the address space 
>> that 
>> can accommodate a larger size, by tweaking page tables rather than copying 
>> all 
>> the bits around.  I’m pretty sure modern glibc realloc uses it.
> 
> AFAIU, this feature will only help us if someone adds code to use it
> in buffer.c:mmap_enlarge.  Or are you saying that the OS will call
> mremap for us automatically when mmap_enlarge attempts to map
> additional pages at the end of an mmaped region?

It could be done explicitly, but my experience was that malloc/realloc would 
just do it for us; we’d just have to use malloc/realloc instead of explicitly 
calling mmap.  I just took a quick look at the glibc sources (2.19, as patched 
and packaged by Debian), and it looks like the use of mmap kicks in by default 
for 128kB or larger allocations, though the threshold can be changed at run 
time.

> If the Linux kernel is the only system that allows implementation of
> mremap, then it doesn't really help in the long run, because on master
> we don't need mmap at all for GNU/Linux systems.

A man page browser at freebsd.org for several platforms seems to indicate that 
NetBSD has picked it up, but neither FreeBSD nor OpenBSD.  I don’t know if 
NetBSD’s realloc will use it, but it’s certainly simpler if we just ignore 
mremap for explicit use, and just bear in mind that realloc may not always have 
to pay the expected copying penalty on all systems….


reply via email to

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