From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Daniel Colascione Newsgroups: gmane.emacs.devel Subject: Re: When should ralloc.c be used? Date: Fri, 28 Oct 2016 23:14:41 -0700 Message-ID: References: <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> <83zilnr8jr.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1477721750 28762 195.159.176.226 (29 Oct 2016 06:15:50 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 29 Oct 2016 06:15:50 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux) Cc: eggert@cs.ucla.edu, monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Oct 29 08:15:46 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 1c0MvZ-0005eh-7C for ged-emacs-devel@m.gmane.org; Sat, 29 Oct 2016 08:15:37 +0200 Original-Received: from localhost ([::1]:53409 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c0MvZ-0003Zz-9S for ged-emacs-devel@m.gmane.org; Sat, 29 Oct 2016 02:15:37 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:42064) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c0Mv2-0003Yw-OS for emacs-devel@gnu.org; Sat, 29 Oct 2016 02:15:05 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c0Muy-0002Tz-O2 for emacs-devel@gnu.org; Sat, 29 Oct 2016 02:15:04 -0400 Original-Received: from dancol.org ([2600:3c01::f03c:91ff:fedf:adf3]:59166) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1c0Muy-0002SO-Ew; Sat, 29 Oct 2016 02:15:00 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date:References:Subject:Cc:To:From; bh=ApMAHqsL12KJ/Y/YY+jverdRNuMGNGBjtrSgLwyGn1c=; b=k7dGJoNMmV9IrsLsSwY3qXJ8CbTOXyaCPXmDDsecm1I9LDt8RnSk/Bl+zyAc+n4uxBPOe67hFbmFfcFKqJxBSocI4E1N18ZeL6X9hjJAMezgIl2qsmFKX6E+etTfNr/AKiJfmqPIRZALVu1NdGpY0WW6UuqwysYuvB+1KTrXRZlCM/XM4lay3D7a4kDexg5mvj5P1TQvlsJw6K+ek25l2PjBitdjO9GMB2T6aHnzfhdA+FUPH55/lrFdUd8a66noE+oQSZ4Q6qT+eNdq5q/YCwFwxQvMofPXUvUSV6Il2C2KNdx4bCLXj4z3dHD/opYQZFcWzGpu8E0ChUePl/2eHQ==; Original-Received: from [73.109.62.221] (helo=dancol-glaptop0) by dancol.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.84_2) (envelope-from ) id 1c0Mup-0005Kk-KZ; Fri, 28 Oct 2016 23:14:51 -0700 In-Reply-To: <83zilnr8jr.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 29 Oct 2016 09:08:56 +0300") X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2600:3c01::f03c:91ff:fedf:adf3 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:208955 Archived-At: Eli Zaretskii writes: >> 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. You can rely on nobody else using that address space, though. This exclusion in itself is valuable. It's like an electric company buying right-of-way for a high-voltage transmission line. Sure, the electric company isn't doing anything with that long strip of land, but the value is in nobody _else_ doing anything with it either. > >> 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? Unmap the original mapping and mapping #2, then fail the higher-level make_magic_ring_buffer operation. Any operation that allocates memory can fail. > >> 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. It's unlikely, but it's a legal failure mode.