[Top][All Lists]

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

Re: When should ralloc.c be used?

From: Eli Zaretskii
Subject: Re: When should ralloc.c be used?
Date: Tue, 25 Oct 2016 19:06:32 +0300

> 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?

> I don’t know if any other systems support it.  The performance savings for 
> one 
> of our favorite systems might be worth the special-casing.  Though, if glibc 
> realloc does the right thing, maybe using malloc/realloc for buffer storage 
> would suffice.

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.

reply via email to

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