mmap behavior - Linux

This is a discussion on mmap behavior - Linux ; The following code behaves differently between kernel 2.4 and kernel 2.6: size_t length = 0x40000000; /* 1GB */ void *addr = mmap (0, length, PROT_NONE, MAP_SHARED|MAP_ANONYMOUS, 0, 0); With kernel 2.4, this 1GB mapping does not account for the process' ...

+ Reply to Thread
Results 1 to 6 of 6

Thread: mmap behavior

  1. mmap behavior

    The following code behaves differently between kernel 2.4 and kernel
    2.6:

    size_t length = 0x40000000; /* 1GB */
    void *addr = mmap (0, length, PROT_NONE, MAP_SHARED|MAP_ANONYMOUS, 0,
    0);

    With kernel 2.4, this 1GB mapping does not account for the process' VM
    size, and this is IMHO the expected behavior, since the reserved
    address space is not accessible (PROT_NONE).

    With kernel 2.6, the 1GB mapping accounts for the process' VM size. The
    process vsize as reported in /proc/pid/statm is > 1GB and I get the
    following entry in pmap output:

    0000002a9557a000 1048576K ---s- /dev/zero (deleted)

    Any advice?
    Thanks,
    Olivier.


  2. Re: mmap behavior


    ochedru@gmail.com wrote:
    > The following code behaves differently between kernel 2.4 and kernel
    > 2.6:
    >
    > size_t length = 0x40000000; /* 1GB */
    > void *addr = mmap (0, length, PROT_NONE, MAP_SHARED|MAP_ANONYMOUS, 0,
    > 0);


    > Any advice?


    I didn't see a question in there. Is this causing some kind of problem
    for you?

    DS


  3. Re: mmap behavior

    This actually causes some trouble because my application relies on
    vsize to perform some self-maintenance tasks.
    With this fake 1GB overhead, this mechanism is broken.
    Is there any workaround? Is there another way to reserve an address
    space range for shared mappings?
    Also, I could not find anything in /proc that would allow me to get the
    "real" vsize.

    Thanks,
    Olivier.


  4. Re: mmap behavior


    ochedru@gmail.com wrote:

    > This actually causes some trouble because my application relies on
    > vsize to perform some self-maintenance tasks.
    > With this fake 1GB overhead, this mechanism is broken.


    On the contrary, the new behavior is superior to the old behavior. It
    makes no sense for address space to be reserved without a corresponding
    mapping.

    > Is there any workaround? Is there another way to reserve an address
    > space range for shared mappings?


    Can you explain your outer problem. Why do you need somehing else to
    reserve space for shared mappings? Why don't you just do it, by not
    using the space you consider reserved?

    > Also, I could not find anything in /proc that would allow me to get the
    > "real" vsize.


    You are getting the real vsize.

    DS


  5. Re: mmap behavior

    > Can you explain your outer problem. Why do you need somehing else to
    > reserve space for shared mappings? Why don't you just do it, by not
    > using the space you consider reserved?


    This reservation is performed by a 3rd party product (ObjectStore).
    This reserved address space range is then used for retrieving objects
    from an ObjectStore database, through a "swap-like" mechanism.

    ObjectStore maps/unmaps pages containing objects in this region as
    reads/writes/commits are performed on the database. It is responsible
    for determining the right address within the range (depending on the
    object size, etc). So address space reservation is necessary to make
    sure nobody else will mmap inside.

    Note such reservation does not account for VM size in e.g. Solaris.

    >
    > > Also, I could not find anything in /proc that would allow me to get the
    > > "real" vsize.

    >
    > You are getting the real vsize.


    As a workaround to my problem, I think I will just substract the size
    of the reserved region to the vsize I get from /proc.

    However, I am curious to know what changed in VM management?

    Thanks!
    Olivier.


  6. Re: mmap behavior

    ochedru@gmail.com wrote:
    > This actually causes some trouble because my application relies on
    > vsize to perform some self-maintenance tasks.
    > With this fake 1GB overhead, this mechanism is broken.


    Your program is broken, because it depends on dubious or even buggy
    behavior.

    > Is there any workaround? Is there another way to reserve an address
    > space range for shared mappings?


    mmap doesn't reserve, it allocates.

    There is no sure-fire way to reserve an address space range without
    actually mapping it.

    A PROT_NONE mapping is a real mapping. It's not valid for mmap to
    simply not create the mapping because the protection is set to
    PROT_NONE. A mapped page that cannot be read or written is not the same
    thing as an unmapped page. It's a mapped page which happens not to have
    write permission or read permission.

    See, you can adjust the protection later with mprotect. You can't
    adjust the protection on unmapped memory with mprotect. The mapping has
    to exist.

    > Also, I could not find anything in /proc that would allow me to get the
    > "real" vsize.


    Can't your program keep track of what it considers to be "not real" and
    subtract it?


+ Reply to Thread