emacs-devel
[Top][All Lists]
Advanced

[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: Sat, 29 Oct 2016 09:08:56 +0300

> Cc: address@hidden, address@hidden, address@hidden
> From: Daniel Colascione <address@hidden>
> 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.



reply via email to

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