when some mmap() limitations in HP-UX 11 (PA-RISC) might get relieved?

From: Chris Markle (cmarkle_at_sendmail.com)
Date: 10/30/04 

Date: Sat, 30 Oct 2004 02:06:24 GMT

Hello,

(Got some good help here on a different issue sometime back so thought I'd
"go to the well" again. Hopefully some HP folks on this list can shed some
light on this, either to the list or to me privately.)

We have an application that we develop that makes very heavy use of mmap().
It runs fine on Solaris and Linux (RH, SuSE); not so fine on HP-UX on
PA-RISC. Some say HP-UX mmap() is "broken"; I just prefer to say "it's
different". Anyhow those differences are causing us difficulties. The main
challenge we have is that we need to mmap(MAP_SHARED) a file, extend the
file, then mmap(MAP_SHARED) the file again with the new length, all in a
single process. One reason this happens is that we have multiple threads (in
same process) mapping the same file, which can grow in length. This is not
supported in HP-UX 11v1 and we just tried it on the new v2 (on PA-RISC) and
it doesn't work there either (although v2 does make improvements to mmap it
doesn't improve _this_).

Question 1: Does anyone reading this know if and when this limitation will
be relieved?

Another possibility would be that if HP-UX 11 v_anything were able to keep
private mappings mmap(MAP_PRIVATE) synchronized with changes made with
write(), our software would (probably) work. (In our understanding of the
hardware/kernel implementation issues behind the HP-UX restrictions, it is
extremely unlikely that HP would go that direction.)

Question 2: Does anyone reading this know if and when this will be supported
(not sure if this is even supported on Linux or Solaris)?

Attached is a test program that demonstrates the failure on HP-UX.
Supposedly this program works on Solaris and Linux. This version requires an
argument that it uses as a filename to create and munge. It stuffs some
data into the file, mmaps it, then extends the file, forks, has the child
mmap the file with the new length, then extends it again and tries to mmap
the file in the parent at the new length while still holding the original
mapping.

Thanks in advance for any help on this...

Chris

Relevant Pages

  • [PATCH, RFD] Unbreaking nommu mmap, v2
    ... A while ago I sent out a patch to change mmap behaviour on nommu targets. ... Currently, the kernel requires a munmap call for every mmap, with the exact same address range; this is inconsistent with behaviour on mmu systems, and complicates the malloc implementation in uClibc. ... Every VMA can be in two states: either it manages a power-of-2 sized compound ... mapping we're capable of supporting ...
    (Linux-Kernel)
  • Re: sharing memory map between processes (same parent)
    ... | 'warm the cache' by getting the inode into memory. ... It might make a difference if the memory remained mapped to some process ... How about we take a look at the approximate steps that mmap needs to ... So, whether the mapping is transferred to a second process, or the second ...
    (comp.unix.programmer)
  • Re: sharing memory map between processes (same parent)
    ... |> I don't know what you mean by slave processes. ... Of course mmap() needs ... file mapping. ... The amount of work for the kernel ...
    (comp.unix.programmer)
  • Re: Porting hard coded code to Solaris
    ... I suppose the same question is valid for mmap as well. ... > mapping, but instead assumes you know what you're doing and replaces the ... That's true of shmat() on some systems too. ... than the shared memory area you need. ...
    (comp.unix.solaris)
  • Re: sharing memory map between processes (same parent)
    ... reference in terms of an open descriptor because the descriptor can be ... closed after mmap(), and the file is still mapped. ... | file content has been loaded into memory, and it won't be until referenced. ... | So, whether the mapping is transferred to a second process, or the second ...
    (comp.unix.programmer)