From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: When should ralloc.c be used? Date: Tue, 25 Oct 2016 19:06:32 +0300 Message-ID: <83oa28wgzb.fsf@gnu.org> References: <831szqhbc2.fsf@gnu.org> <87d1itt79z.fsf_-_@users.sourceforge.net> <7baa18d4-2b09-caa8-005e-29008a383ad1@cs.ucla.edu> <83mvhwrgd5.fsf@gnu.org> <8539f38f-9a11-44c3-4de7-bb974c96206c@cs.ucla.edu> <838ttfnmev.fsf@gnu.org> <837f8znk8f.fsf@gnu.org> <83zilvm2ud.fsf@gnu.org> <83r377m0i8.fsf@gnu.org> <83eg36n6v5.fsf@gnu.org> <83shrl523p.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: blaine.gmane.org 1477412416 3531 195.159.176.226 (25 Oct 2016 16:20:16 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 25 Oct 2016 16:20:16 +0000 (UTC) Cc: emacs-devel@gnu.org To: Ken Raeburn Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Oct 25 18:20:08 2016 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bz4Ri-0003jC-82 for ged-emacs-devel@m.gmane.org; Tue, 25 Oct 2016 18:19:26 +0200 Original-Received: from localhost ([::1]:56311 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bz4Rk-0006dh-AH for ged-emacs-devel@m.gmane.org; Tue, 25 Oct 2016 12:19:28 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33853) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bz4FM-0003xi-No for emacs-devel@gnu.org; Tue, 25 Oct 2016 12:06:44 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bz4FI-000716-Oa for emacs-devel@gnu.org; Tue, 25 Oct 2016 12:06:40 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:45217) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bz4FI-000710-Lv; Tue, 25 Oct 2016 12:06:36 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1379 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1bz4FH-0000hu-BW; Tue, 25 Oct 2016 12:06:36 -0400 In-reply-to: (message from Ken Raeburn on Mon, 24 Oct 2016 23:12:40 -0400) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:208779 Archived-At: > From: Ken Raeburn > 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.