Argument shmaddr in shmat() - HP UX

This is a discussion on Argument shmaddr in shmat() - HP UX ; From man shmat HP-UX 11i Version 2; August 2003 --------------------- void *shmat(int shmid, void *shmaddr, int shmflg); int shmdt(void *shmaddr); [snip] If the shared memory segment has never been attached to by any process prior to the current shmat() call, ...

+ Reply to Thread
Results 1 to 7 of 7

Thread: Argument shmaddr in shmat()

  1. Argument shmaddr in shmat()

    From man shmat
    HP-UX 11i Version 2; August 2003

    ---------------------
    void *shmat(int shmid, void *shmaddr, int shmflg);

    int shmdt(void *shmaddr);

    [snip]
    If the shared memory segment has never been attached to by any
    process prior to the current shmat() call, shmaddr must be specified
    as zero and the segment is attached at a location selected by the
    operating system.
    [snip]

    ---------------------

    Does it mean that if the only process works with the shared memory
    segment, then shmaddr must be set 0 in shmat(), i.e.
    shmat (shmat, 0, shmflg) ?


    Alex Vinokur
    email: alex DOT vinokur AT gmail DOT com
    http://mathforum.org/library/view/10978.html
    http://sourceforge.net/users/alexvn


  2. Re: Argument shmaddr in shmat()

    Alex Vinokur wrote:
    > From man shmat
    > HP-UX 11i Version 2; August 2003
    >
    > ---------------------
    > void *shmat(int shmid, void *shmaddr, int shmflg);
    >
    > int shmdt(void *shmaddr);
    >
    > [snip]
    > If the shared memory segment has never been attached to by any
    > process prior to the current shmat() call, shmaddr must be specified
    > as zero and the segment is attached at a location selected by the
    > operating system.
    > [snip]
    >
    > ---------------------
    >
    > Does it mean that if the only process works with the shared memory
    > segment, then shmaddr must be set 0 in shmat(), i.e.
    > shmat (shmat, 0, shmflg) ?


    Well, you don't really say what you mean by "the only process works".
    And I certainly hope you aren't using "int shmat;" as your shmid field
    either...

    Assuming what you mean is if this holds if only a single process creates
    and attaches a shared memory segment -- yes, that single process still
    passes 0 on the first attach [because the OS has already chosen a
    shared virtual range for the object]. It is permitted if the process
    does shmdt() and then shmat() again later for the process to pass 0
    or the address previously given via the first shmat().

    The big exception (since you cited the 11iv2 man page) is if this is
    11iv2 on IPF -- there you can be running a process in MPAS layout.
    MPAS processes may pass in any virtual address they want to shmat()
    [if they want to put the segment somewhere in particular].

    Don

  3. Re: Argument shmaddr in shmat()

    On Dec 23, 2:48*pm, Don Morris wrote:
    > Alex Vinokur wrote:
    > > From man shmat
    > > HP-UX 11i Version 2; August 2003

    >
    > > ---------------------
    > > void *shmat(int shmid, void *shmaddr, int shmflg);

    >
    > > * * * int shmdt(void *shmaddr);

    >
    > > [snip]
    > > * * * If the shared memory segment has never been attached to by any
    > > process prior to the current shmat() call, shmaddr must be specified
    > > as zero and the segment is attached at a location selected by the
    > > operating system.
    > > [snip]

    >
    > > ---------------------

    >
    > > Does it mean that if the only process works with the shared memory
    > > segment, then shmaddr must be set 0 in shmat(), i.e.
    > > shmat (shmat, 0, shmflg) ?

    >
    > Well, you don't really say what you mean by "the only process works".
    > And I certainly hope you aren't using "int shmat;" as your shmid field
    > either...
    >
    > Assuming what you mean is if this holds if only a single process creates
    > and attaches a shared memory segment -- yes, that single process still
    > passes 0 on the first attach [because the OS has already chosen a
    > shared virtual range for the object]. It is permitted if the process
    > does shmdt() and then shmat() again later for the process to pass 0
    > or the address previously given via the first shmat().
    >
    > The big exception (since you cited the 11iv2 man page) is if this is
    > 11iv2 on IPF -- there you can be running a process in MPAS layout.
    > MPAS processes may pass in any virtual address they want to shmat()
    > [if they want to put the segment somewhere in particular].
    >
    > Don- Hide quoted text -
    >
    > - Show quoted text -


    So there's no way to map shared memory to a specific address on hpux?

  4. Re: Argument shmaddr in shmat()

    Sela Lerer wrote:
    > So there's no way to map shared memory to a specific address on hpux?


    As stated, only MPAS model processes allow this using SysV shared
    memory. You could try to get something much the same (as long as
    it didn't need to live beyond process context like SysV) using
    mmap() with MAP_FIXED|MAP_SHARED|MAP_ANONYMOUS... but if you're
    non-MPAS, you stand a really good chance of getting EINVAL while
    you look for a free address range.

    For those curious as to _why_ -- it is because HP-UX historically is
    and was a Global Address Space OS -- all shared objects come from a
    single global address space, and as such -- no single process could
    willy-nilly pick a VA from that range because it was very unlikely
    to be available (what a single process can see isn't at all the same
    as what the system knows about).

    This was the way it was because PA-RISC didn't support virtual
    aliasing all that well -- and hence you couldn't have a single
    physical page with multiple different translations as a general
    model... which is what required physical pages shared across
    multiple processes to use the same virtual address... and hence,
    the global address space.

    IPF has better aliasing support -- which is what MPAS is built on.
    However, the translation handling of aliases can result in long
    hash collision chains and impede performance, so you don't want to
    run _everything_ as MPAS either. Only what you truly need to.

    Don

  5. Re: Argument shmaddr in shmat()

    On Dec 23, 3:41 pm, Don Morris wrote:
    > Sela Lerer wrote:
    > > So there's no way to map shared memory to a specific address on hpux?

    >
    > As stated, only MPAS model processes allow this using SysV shared
    > memory. You could try to get something much the same (as long as
    > it didn't need to live beyond process context like SysV) using
    > mmap() with MAP_FIXED|MAP_SHARED|MAP_ANONYMOUS... but if you're
    > non-MPAS, you stand a really good chance of getting EINVAL while
    > you look for a free address range.
    >
    > For those curious as to _why_ -- it is because HP-UX historically is
    > and was a Global Address Space OS -- all shared objects come from a
    > single global address space, and as such -- no single process could
    > willy-nilly pick a VA from that range because it was very unlikely
    > to be available (what a single process can see isn't at all the same
    > as what the system knows about).
    >
    > This was the way it was because PA-RISC didn't support virtual
    > aliasing all that well -- and hence you couldn't have a single
    > physical page with multiple different translations as a general
    > model... which is what required physical pages shared across
    > multiple processes to use the same virtual address... and hence,
    > the global address space.
    >
    > IPF has better aliasing support -- which is what MPAS is built on.
    > However, the translation handling of aliases can result in long
    > hash collision chains and impede performance, so you don't want to
    > run _everything_ as MPAS either. Only what you truly need to.
    >
    > Don


    Thanks Don, that's a great answer. Not what I was hoping to hear, but
    a great answer ;-)

  6. Re: Argument shmaddr in shmat()

    On Dec 23, 4:57*pm, Sela Lerer wrote:
    > On Dec 23, 3:41 pm, Don Morris wrote:
    >
    >
    >
    >
    >
    > > Sela Lerer wrote:
    > > > So there's no way to map shared memory to a specific address on hpux?

    >
    > > As stated, only MPAS model processes allow this using SysV shared
    > > memory. You could try to get something much the same (as long as
    > > it didn't need to live beyond process context like SysV) using
    > > mmap() with MAP_FIXED|MAP_SHARED|MAP_ANONYMOUS... but if you're
    > > non-MPAS, you stand a really good chance of getting EINVAL while
    > > you look for a free address range.

    >
    > > For those curious as to _why_ -- it is because HP-UX historically is
    > > and was a Global Address Space OS -- all shared objects come from a
    > > single global address space, and as such -- no single process could
    > > willy-nilly pick a VA from that range because it was very unlikely
    > > to be available (what a single process can see isn't at all the same
    > > as what the system knows about).

    >
    > > This was the way it was because PA-RISC didn't support virtual
    > > aliasing all that well -- and hence you couldn't have a single
    > > physical page with multiple different translations as a general
    > > model... which is what required physical pages shared across
    > > multiple processes to use the same virtual address... and hence,
    > > the global address space.

    >
    > > IPF has better aliasing support -- which is what MPAS is built on.
    > > However, the translation handling of aliases can result in long
    > > hash collision chains and impede performance, so you don't want to
    > > run _everything_ as MPAS either. Only what you truly need to.

    >
    > > Don

    >
    > Thanks Don, that's a great answer. Not what I was hoping to hear, but
    > a great answer ;-)- Hide quoted text -
    >
    > - Show quoted text -


    Hi Don,
    The actual address is not so important, the reason we wanted to use
    the address is to make sure that we have the right alignment of the
    shared memory segments. For example, assuming that we want to use
    1GBytes per shared memory segment, and we would like to create 10 such
    segment, how we can get the 1GBytes alignment for each of the
    segments ? any suggestions ?

  7. Re: Argument shmaddr in shmat()

    mbnshtck@gmail.com wrote:
    > Hi Don,
    > The actual address is not so important, the reason we wanted to use
    > the address is to make sure that we have the right alignment of the
    > shared memory segments. For example, assuming that we want to use
    > 1GBytes per shared memory segment, and we would like to create 10 such
    > segment, how we can get the 1GBytes alignment for each of the
    > segments ? any suggestions ?


    Well, obviously you're talking about 64-bit virtual address space...
    because you can't have 10Gb of 32-bit shared virtual objects without
    using a few Memory Windows.

    The key for the virtual address layout would be shmget(), not shmat()
    since that's where the address for the segment is actually chosen.
    Note that shmget() doesn't take alignment flags or size... so, in
    short, there's no API method of getting this alignment.

    In practice, 11iv2 will align the segments based on the page size
    hint given to the object -- which is either the Data page size of
    the binary (via chatr ) or [if the binary doesn't have a hint] via
    the vps_pagesize tunable. Since the tunable is capped at 64Mb, you'll
    have to go the chatr +pd route. (And yes, this can result in a larger
    heap physical consumption... I don't know what your tradeoffs are here,
    just describing the options).

    Alternately, 11iv3 shifted to aligning on the segment size [shifted down
    to the next supported page size of the processor] instead of the
    underlying page size which would give you the behavior you wish.

    Don

+ Reply to Thread