[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.
- Re: When should ralloc.c be used?, (continued)
- Re: When should ralloc.c be used?, Daniel Colascione, 2016/10/28
- Re: When should ralloc.c be used?, Eli Zaretskii, 2016/10/28
- Re: When should ralloc.c be used?, Daniel Colascione, 2016/10/28
- Re: When should ralloc.c be used?, Eli Zaretskii, 2016/10/28
- Re: When should ralloc.c be used?, Daniel Colascione, 2016/10/28
- Re: When should ralloc.c be used?, Eli Zaretskii, 2016/10/28
- Re: When should ralloc.c be used?, Stefan Monnier, 2016/10/28
- Re: When should ralloc.c be used?, Eli Zaretskii, 2016/10/28
- Re: When should ralloc.c be used?, Stefan Monnier, 2016/10/28
- Re: When should ralloc.c be used?, Daniel Colascione, 2016/10/28
- Re: When should ralloc.c be used?,
Eli Zaretskii <=
- Re: When should ralloc.c be used?, Daniel Colascione, 2016/10/29
- Re: When should ralloc.c be used?, Stefan Monnier, 2016/10/28
- Re: When should ralloc.c be used?, Jérémie Courrèges-Anglas, 2016/10/28
- Re: When should ralloc.c be used?, Stefan Monnier, 2016/10/28
- Re: When should ralloc.c be used?, Jérémie Courrèges-Anglas, 2016/10/28
- Re: When should ralloc.c be used?, Daniel Colascione, 2016/10/28
- Re: When should ralloc.c be used?, Stefan Monnier, 2016/10/24
- Re: When should ralloc.c be used?, Eli Zaretskii, 2016/10/24
- Re: When should ralloc.c be used?, Stefan Monnier, 2016/10/25
- Re: When should ralloc.c be used?, Eli Zaretskii, 2016/10/25