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: Sat, 29 Oct 2016 09:08:56 +0300 Message-ID: <83zilnr8jr.fsf@gnu.org> References: <838ttfnmev.fsf@gnu.org> <837f8znk8f.fsf@gnu.org> <83zilvm2ud.fsf@gnu.org> <83r377m0i8.fsf@gnu.org> <83eg36n6v5.fsf@gnu.org> <83shrl523p.fsf@gnu.org> <83eg354ux3.fsf@gnu.org> <4f0c2868-d408-a5c4-d5a8-90dae750eb33@dancol.org> <878tt9ggdk.fsf@ritchie.wxcvbn.org> <83k2cssypt.fsf@gnu.org> <6350b2df-fde9-e716-d279-9f29438f8ee5@dancol.org> <83d1ikswsf.fsf@gnu.org> <7ab47b94-c662-1351-0dd3-ed5269842438@dancol.org> <83bmy4stax.fsf@gnu.org> <83a8dosls8.fsf@gnu.org> <96b0015e-a6c9-e829-2c78-36e1817826ea@dancol.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1477721387 16420 195.159.176.226 (29 Oct 2016 06:09:47 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 29 Oct 2016 06:09:47 +0000 (UTC) Cc: eggert@cs.ucla.edu, monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Daniel Colascione Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Oct 29 08:09:43 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 1c0MpW-0001Cz-VQ for ged-emacs-devel@m.gmane.org; Sat, 29 Oct 2016 08:09:23 +0200 Original-Received: from localhost ([::1]:53384 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c0MpZ-0001jS-EZ for ged-emacs-devel@m.gmane.org; Sat, 29 Oct 2016 02:09:25 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41040) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c0Mp3-0001jC-L6 for emacs-devel@gnu.org; Sat, 29 Oct 2016 02:08:54 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c0Moz-0000aK-LR for emacs-devel@gnu.org; Sat, 29 Oct 2016 02:08:53 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:47345) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c0Moz-0000aE-Hd; Sat, 29 Oct 2016 02:08:49 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:4582 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1c0Moy-0000aM-7K; Sat, 29 Oct 2016 02:08:48 -0400 In-reply-to: <96b0015e-a6c9-e829-2c78-36e1817826ea@dancol.org> (message from Daniel Colascione on Fri, 28 Oct 2016 08:41:48 -0700) 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:208954 Archived-At: > Cc: monnier@iro.umontreal.ca, eggert@cs.ucla.edu, emacs-devel@gnu.org > From: Daniel Colascione > Date: Fri, 28 Oct 2016 08:41:48 -0700 > > >> Reserving address space is useful for making sure you have a contiguous > >> range of virtual addresses that you can use later. > > > > But if committing more pages from the reserved range is not guaranteed > > to succeed, I cannot rely on getting that contiguous range of > > addresses, can I? > > You already _have_ the range of addresses. You just can't do anything > with them yet. It's no use "having" the addresses, in the above sense, if I can't rely on being able to do anything with them later. > Here's another use case: magic ring buffers. (Where you put two > consecutive views of the same file in memory next to each other so that > operations on the ring buffer don't need to be split even in cases where > they'd wrap the end of the ring.) > > Say on our 1GB RAM, 1GB swap system we want to memory-map a 5GB ring > buffer log file. We can do it safely and atomically like this: > > 1) Reserve 10GB of address space with an anonymous PROT_NONE mapping; > the mapping is at $ADDR > 2) Memory-map our log file at $ADDR with PROT_READ|PROT_WRITE; (the > mapping is file-backed, not anonymous, so it doesn't count against > system commit charge) > 3) Memory-map the log file _again_ at $ADDR+5GB If 3) fails, what do you do? > Now we have a nice mirrored view of our ring buffer, and thanks to the > PROT_NONE mapping we set up in step one, no other thread was able to > sneak in the middle and allocate something in the [$ADDR+5GB,$ADDR+10GB) > range and spoil our ability to set up the mirroring. > > In this instance, setting aside address space without allocating backing > storage for it turned out to be very useful. Not if PROT_READ|PROT_WRITE call fails. But if, as Stefan says, this will "never" happen, then the problem doesn't exist in practice, and for all practical purposes what I thought should happen, does happen, even if in theory it can fail.