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 08:41:48 -0700 Message-ID: <96b0015e-a6c9-e829-2c78-36e1817826ea@dancol.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> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: blaine.gmane.org 1477671397 29762 195.159.176.226 (28 Oct 2016 16:16:37 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 28 Oct 2016 16:16:37 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 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 Fri Oct 28 18:16:33 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 1c09pG-0004SB-I0 for ged-emacs-devel@m.gmane.org; Fri, 28 Oct 2016 18:16:15 +0200 Original-Received: from localhost ([::1]:50148 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c09pE-0003xs-0c for ged-emacs-devel@m.gmane.org; Fri, 28 Oct 2016 12:16:12 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33058) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c09I3-0007Ra-K3 for emacs-devel@gnu.org; Fri, 28 Oct 2016 11:41:56 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c09I0-0005aa-HC for emacs-devel@gnu.org; Fri, 28 Oct 2016 11:41:55 -0400 Original-Received: from dancol.org ([2600:3c01::f03c:91ff:fedf:adf3]:49024) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1c09I0-0005aJ-7s; Fri, 28 Oct 2016 11:41:52 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:Cc:References:To:Subject; bh=QbGvPkTub+qF7bNt/dUwup+9p6gqaDD02WGuLox4WjU=; b=KkeypTIU8yp8bgIn+xFpTCdsnXS9T8Mb2LR0nrCBcYr6SQ4D9088xHUe+1eqrKhjby9XNXq09PEAc3xffy9JBa3naBKNvFSoS6ZQeFq1fxwhZ2gHENPVYy2jARk+euUrPViZ6Qm3RFttlUvl5lHA0MgcPWtif/WX0rGV3EBnYj5jNCSb1N3C0d1WOgOOvvx3Xex5ewh/bDqdyIP8yzDAejX8uRjAO/dIlf+ggyUpMSmBaf16nY4lPMNzXW3pg9p1wi1y7gdqJ7OQjfyJD5Lz48GW9bSkS9+uRgzMTSZRuk3ya5zzuhXhlVN0hnNf+6zIhV/Y0atJyxiYSkRXp59NFw==; Original-Received: from c-73-97-199-232.hsd1.wa.comcast.net ([73.97.199.232] helo=[192.168.1.173]) by dancol.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1c09Hy-00085Z-W7; Fri, 28 Oct 2016 08:41:51 -0700 In-Reply-To: <83a8dosls8.fsf@gnu.org> 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:208950 Archived-At: On 10/28/2016 05:25 AM, Eli Zaretskii wrote: >> Cc: monnier@iro.umontreal.ca, eggert@cs.ucla.edu, emacs-devel@gnu.org >> From: Daniel Colascione >> Date: Fri, 28 Oct 2016 02:52:19 -0700 >> >>> If reserving a range of addresses doesn't necessarily mean they will >>> be later available for committing, then what is the purpose of >>> reserving them in the first place? What good does it do? >> >> 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. 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 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. > >>> We have in w32heap.c:mmap_realloc code that attempts to commit pages >>> that were previously reserved. That code does recover from a failure >>> to commit, but such a failure is deemed unusual and causes special >>> warnings under debugger. I never saw these warnings happen, except >>> when we had bugs in that code. You seem to say that this is based on >>> false premises, and there's nothing unusual about MEM_COMMIT to fail >>> for the range of pages previously reserved with MEM_RESERVE. >> >> The MEM_COMMIT failure might be rare in practice --- systems have a lot >> of memory these days --- but MEM_COMMIT failing for a memory region >> previously reserved with MEM_RESERVE is perfectly legal. > > I can only say that I never saw that happening. > > Thanks. >